Description
Proposal
Increase the size of TypeId's hash from 64 bits to 128 bits.
With a 64 bit hash, the probability of collision is 1 in 2^32 (due to the birthday bound) -- 1 in roughly 4 billion. This is a number low enough that it seems very likely that some program in the wild has experienced a TypeId collision. My suspicion is that the fact that idiomatic Rust does not heavily use TypeId or Any (at least, in code paths which commonly occur -- it's much more frequently used in error handling) is an explanation for why it has never been detected in the wild.
A 128 bit hash increases the probability of collision to 1 in 2^64, which is considerably larger -- 1 in roughly 18 quintillion. This is high enough that its very likely that we could store all types of all compilations of all Rust programs to date without collisions.
Note that this approach does not remove the possibility of a collision, just makes it very unlikely. However, it also does not preclude solving this problem in a better way in the future. The goal is just to reduce the likelihood of issues that occur in practice from "could happen" to "almost certainly will not happen". This allows programs and libraries which depends on Any/TypeId in their designs to use it with more confidence.
(A preliminary/draft implementation is available at rust-lang/rust#109953)
P.S. Not sure if MCP is correct for this. It does seem like a t-compiler implementation detail, rather than something public-facing like an RFC.
Mentors or Reviewers
N/A
Process
The main points of the Major Change Process are as follows:
- File an issue describing the proposal.
- A compiler team member or contributor who is knowledgeable in the area can second by writing
@rustbot second.- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
-C flag, then full team check-off is required. - Compiler team members can initiate a check-off via
@rfcbot fcp mergeon either the MCP or the PR.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
- Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.
You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.