Tracking Issue for type_info
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
This is a tracking issue for the project goal https://github.com/rust-lang/rust-project-goals/issues/406
The feature gate for the issue is #![feature(type_info)].
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.
Steps
- Implement the goal
- Discuss general reflection with the lang team
- Discuss https://github.com/rust-lang/rust/issues/41875 and not requiring
'staticwith the lang team - Write an RFC
- Adjust documentation (see instructions on rustc-dev-guide)
- Style updates for any new syntax (nightly-style-procedure)
- Style team decision on new formatting
- Formatting for new syntax has been added to the Style Guide
- (non-blocking) Formatting has been implemented in
rustfmt
- Stabilization PR (see instructions on rustc-dev-guide)
Unresolved Questions
- Should we use fine grained (many) intrinsics for individual information or keep the one big intrinsic returning an enum of the information?
- what semver implications does all this have and what guarantees of semver do we retain?
- should we even do this at all? Reflection allows causing monomorphization time errors similar to
const { assert!(size_of::<T>(), 5) }, but for much more fine-grained details of a generic parameterT. - Is something lifetime-aware even possible at all?
- Should we use a non-const-eval based scheme (const generics based or even proc macro based?)
Implementation history
- https://github.com/rust-lang/rust/pull/146923
- https://github.com/rust-lang/rust/pull/151019
- https://github.com/rust-lang/rust/pull/151031
- https://github.com/rust-lang/rust/pull/151118
- https://github.com/rust-lang/rust/pull/151119
- https://github.com/rust-lang/rust/pull/151123
- https://github.com/rust-lang/rust/pull/151222
- https://github.com/rust-lang/rust/pull/151239
- https://github.com/rust-lang/rust/pull/151142
- https://github.com/rust-lang/rust/pull/152003
- https://github.com/rust-lang/rust/pull/152173
- https://github.com/rust-lang/rust/pull/152381
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
This is a tracking issue for the type_info goal, using the #![feature(type_info)] feature gate; no implementation file, test, or entry point is named. Start with the linked project goal and implementation-history pull requests, then review the unresolved reflection, lifetime, semver, and intrinsic-design questions; done is defined by the unchecked implementation, RFC, documentation, style, and stabilization milestones.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 15/100