Proposal

Stable hashing involves various types, traits, modules, etc., and these are named inconsistently. The most important inconsistency is that some things use StableHash and some use HashStable and it's difficult to remember which is which. There are also some other minor inconsistencies.

This situation is best exemplified by the trait named HashStableContext which is impl'd by a single type named StableHashingContext. Yuk.

The following shows the planned renamings.

UNCHANGED

rustc-stable-hash   (crate)
StableHasher        (renaming of `StableSipHasher128` from `rustc-stable-hash`)
StableHasherHash(?) (renaming of `SipHasher128Hash` from `rustc-stable-hash`)
ToStableHashKey     (trait)
to_stable_hash_key  (trait method)
stable_hash         (newtype_index attribute)

CHANGED

HashStable           -> StableHash           (trait)
hash_stable          -> stable_hash          (trait method)
HashStable           -> StableHash           (derive)
HashStable_NoContext -> StableHash_NoContext (derive)
HashStableContext    -> StableHashCtxt       (trait/trait bound)
span_hash_stable     -> stable_hash_span     (trait method)
StableHashingContext -> StableHashState      (struct)
stable_hasher        -> stable_hash          (mod in rustc_data_structures)
hash_stable          -> stable_hash          (mod in rustc_macros)
HashingControls      -> StableHashControls   (struct)
AbiHashStable        -> StableAbiHash        (trait)
abi_hash             -> stable_abi_hash      (trait method)

Rationale

• Want a consistent order, and StableHash is better than HashStable.
  • "stable hash" is the English noun phrase.
  • "stable hash" could serve as an English verb phrase at a stretch (e.g. "I will stable-hash this value"), though "I will compute the stable hash of this value" is more reasonable.
  • In contrast, "hash stable" doesn't really make sense in English as a noun phrase or verb phrase.
  • rustc-stable-hash is a published crate and is the hardest name to change.
  • We have a trait called StableOrd (not OrdStable).
• Want consistent forms, e.g. replace the rarely used Hashing with Hash.
• StableHashCtxt: this trait is used a lot so it uses Ctxt instead of Context, because it's good for highly-used names to be short.
  • There are many existing Hcx/hcx names in use with this trait, so preserving the use of Ctxt/Context is good.
• StableHashState: this struct avoids Context/Ctxt to prevent confusion with the trait.
  • This name isn't used as much, and will be used even less if/when Simplify HashStable rust#155018 merges.

Mentors or Reviewers

I can do the work. Reviewing will be tedious but easy.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.