-
-
Notifications
You must be signed in to change notification settings - Fork 14.5k
Open
Labels
B-experimentalBlocker: In-tree experiment; RFC pending, not yet approved or unneeded (requires FCP to stabilize).Blocker: In-tree experiment; RFC pending, not yet approved or unneeded (requires FCP to stabilize).C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCF-type_info#![feature(type_info)]#![feature(type_info)]T-langRelevant to the language teamRelevant to the language teamT-libsRelevant to the library team, which will review and decide on the PR/issue.Relevant to the library team, which will review and decide on the PR/issue.
Description
This is a tracking issue for the project goal rust-lang/rust-project-goals#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 Tracking issue for non_static_type_id #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
- Reflection MVP #146923
- Make
Type::ofsupport unsized types #151019 - Support arrays in type reflection #151031
- Support slices in type reflection #151118
- Support pointers in type reflection #151119
- Support primitives in type info reflection #151123
- feat: Support references in reflection type info #151222
- Support trait objects in type info reflection #151239
- Support ADT types in type info reflection #151142
- Reflection TypeId::trait_info_of #152003
- Reflection TypeKind::FnPtr #152173
- Do not require
'staticfor obtaining reflection information. #152381
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
B-experimentalBlocker: In-tree experiment; RFC pending, not yet approved or unneeded (requires FCP to stabilize).Blocker: In-tree experiment; RFC pending, not yet approved or unneeded (requires FCP to stabilize).C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCF-type_info#![feature(type_info)]#![feature(type_info)]T-langRelevant to the language teamRelevant to the language teamT-libsRelevant to the library team, which will review and decide on the PR/issue.Relevant to the library team, which will review and decide on the PR/issue.