Repository navigation
reflection and comptime #406
Description
| Metadata | |
|---|---|
| Contact | @oli-obk |
| Team(s) | compiler (@oli-obk), lang (@scottmcm), libs (@joshtriplett), types |
| Goal document | 2026/reflection-and-comptime |
Summary
Finish the implemented reflection scheme based on const fn that can only be called at compile time.
Validate it against existing reflection libraries by giving them a nightly feature that obsoletes having derives and makes the derives no-ops.
Obtain T-lang and T-libs buy-in for the scheme and write an RFC.
This proposal is solely for producing const eval values, not for putting types back into the type system.
That will be a follow-up once this proposal has a merged MVP.
This issue is intended for status updates only.
For general questions or comments, please contact a goal owner or post in the Zulip topic.
Activity
nikomatsakis commentedon Sep 16, 2025
This issue is intended for status updates only.
For general questions or comments, please contact the owner(s) directly.
oli-obk commentedon Oct 22, 2025
I implemented an initial MVP supporting only tuples and primitives (tho those are just opaque things you can't interact with further), and getting offsets for the tuple fields as well as the size of the tuple: rust-lang/rust#146923
There are two designs of how to expose this from a libs perspective, but after a sync meeting with scottmcm yesterday we came to the conclusion that neither is objectively better at this stage so we're just going to go with the nice end-user UX version for now. For details see the PR description.
Once the MVP lands, I will mentor various interested contributors who will keep adding fields to the Type struct and variants the TypeKind enum.
The next major step is restricting what information you can get from structs outside of the current module or crate. We want to honor visibility, so an initial step would be to just never show private fields, but we want to explore allowing private fields to be shown either just within the current module or via some opt-in marker trait
nikomatsakis commentedon Nov 12, 2025
Another related PR:
rust-lang/rust#148820
oli-obk commentedon Dec 15, 2025
Updates
Blockers
oli-obk commentedon Jan 14, 2026
'staticrequirement in Remove 'static requirement on try_as_dyn rust#150161oli-obk commentedon Feb 9, 2026
Type::ofsupport unsized types rust#151019There is ongoing work for Adts and function pointers, both of which will land as MVPs and will need some work to make them respect semver or generally become useful in practice
Removing the
'staticbound fromtry_as_dynturned out to have many warts, so I'm limiting it to a much smaller subset and will have borrowck emit the'staticrequirement if the other rules do not apply (instead of having an unconditional'staticrequirement)oli-obk commentedon Mar 19, 2026
'staticones'staticfor obtaining reflection information. rust#152381oli-obk commentedon Apr 22, 2026
No changes since last time.
I'm writing a document for the lang team meeting on reflection next week
2 remaining items
tomassedovic commentedon May 5, 2026
This is a continuing project goal, and the updates below this comment will be for the new period 2026
oli-obk commentedon Jun 17, 2026
We're changing the design away from one big enum with lots of structs inside to a more "many small functions giving you pieces" system. This has various reasons:
@SpriteOvO has started this work in
Type::sizefield toTypeId::sizemethod fortype_inforust#156223TypeIdmethodsvariantsfieldsfieldfortype_inforust#156403I landed an MVP of comptime fns in
and started using it for the reflection methods in
There's still lots to figure out around comptime and how it interacts with const traits, because in contrast to
const Traitbounds, which are essentially sugar forTrait + rustc_comptime!(Trait)bounds, we do actually need something that adds bounds that can only be used at compile time (therustc_comptime!macro doesn't actually exist).oli-obk commentedon Jul 24, 2026
has landed. You can now
try_as_dynon anyT, even without a'staticbound. On the negative side, this now means we returnNonein more cases. See the documentation oftry_as_dynfor details.moves over some more information from the big enum to individual methods. This made me realize we need the ability to fetch information directly for enum variants (name, non_exhaustive, ...). While we could just add a variant index to all the intrinsics, it would be nicer if we did the FRT thing and just had pattern types for individual variants, and were able to fetch information from them. Short term we'll just use the variant index and have a
Variantdata structure that wraps the index and the base type's typeid.oli-obk commentedon Sep 9, 2026
@yara-blue has made good progress on moving to the "many intrinsics" design (in contrast to the less flexible "one big enum" design):
TypeId::is_signedmethod rust#160925Once the transformation is complete, we'll add more methods until we have parity with at least bevy-reflect. Then we'll do an experiment to see if we can make the bevy-reflect derives be no-ops and instead have a single reflection based impl for
bevy_reflect::Reflectoli-obk commentedon Oct 9, 2026
Yara continues cleaning up the API and the compiler impl
She's also creating demos (e.g. a debug printer that uses
Debugwhere it is there and reflection for debugging otherwise), and discovering what APIs are missing to enable some use cases.