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:
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.
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 aTypeIdcollision. My suspicion is that the fact that idiomatic Rust does not heavily useTypeIdorAny(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/TypeIdin 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:
@rustbot second.-C flag, then full team check-off is required.@rfcbot fcp mergeon either the MCP or the PR.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.