Description
Proposal
Currently, the compiler just uses DefId everywhere. This is bad for correctness (you just get ICEs instead of compiler errors when passing an ID of the wrong kind) and documentation (DefId doesn't clearly document which kinds are expected).
Instead, we should be using more strongly typed versions that assert that correct IDs are passed at compile time and clearly document which kinds are expected.
This MCP proposes to add strongly typed versions of def ids like ModDefId or TraitDefId. These types will be used as much as possible when a specific def kind is expected.
When a specific set of multiple def kinds is accepted, we can also create newtypes for such a set specifically.
This will lead to a hierarchy of (local) def ids. Casting up (like from a TraitDefId to a DefId) will be possible using From and IntoQueryParam impls to make it as implicit as possible as there is no concern with such casts. I am not entirely sure yet on how to best write the required macros and impls to make sure that the addition of new IDs is as simple as possible, but this is my goal.
Local versions of all the typed def ids will exist as well.
I have already created an MVP PR for ModDefId and the results are quite promising: rust-lang/rust#110862
Mentors or Reviewers
I will not have the time to implement it all by myself, but I may be able to do some of the generic work necessary for making it easy to add new typed def ids. This is a big change affecting all regions of code.
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.