commit f57eac1bf98cb5d578e3364b64365ec398c137df
author rust-bors[bot] <122020455+rust-bors[bot]@users.noreply.github.com> Sat Jan 10 15:00:14 2026 +0000
committer GitHub <noreply@github.com> Sat Jan 10 15:00:14 2026 +0000
tree f64d24836a2894ae767da224046a806984f78b3f
parent 1b9ae9eddcbd3b0105a0828e323c6db5f1e6ad0c
parent 82028b0f9a9695edd3f70d54234df0bb61e4184d

Auto merge of #146923 - oli-obk:comptime-reflect, r=BoxyUwU
Reflection MVP

I am opening this PR for discussion about the general design we should start out with, as there are various options (that are not too hard to transition between each other, so we should totally just pick one and go with it and reiterate later)

r? @scottmcm and @joshtriplett

project goal issue: https://github.com/rust-lang/rust-project-goals/issues/406
tracking issue: https://github.com/rust-lang/rust/issues/146922

The design currently implemented by this PR is

* `TypeId::info` (method, usually used as `id.info()` returns a `Type` struct
* the `Type` struct has fields that contain information about the type
* the most notable field is `kind`, which is a non-exhaustive enum over all possible type kinds and their specific information. So it has a `Tuple(Tuple)` variant, where the only field is a `Tuple` struct type that contains more information (The list of type ids that make up the tuple).
* To get nested type information (like the type of fields) you need to call `TypeId::info` again.
* There is only one language intrinsic to go from `TypeId` to `Type`, and it does all the work

An alternative design could be

* Lots of small methods (each backed by an intrinsic) on `TypeId` that return all the individual information pieces (size, align, number of fields, number of variants, ...)
* This is how C++ does it (see https://lemire.me/blog/2025/06/22/c26-will-include-compile-time-reflection-why-should-you-care/ and https://isocpp.org/files/papers/P2996R13.html#member-queries)
* Advantage: you only get the information you ask for, so it's probably cheaper if you get just one piece of information for lots of types (e.g. reimplementing size_of in terms of `TypeId::info` is likely expensive and wasteful)
* Disadvantage: lots of method calling (and `Option` return types, or "general" methods like `num_fields` returning 0 for primitives) instead of matching and field accesses
* a crates.io crate could implement `TypeId::info` in terms of this design

The backing implementation is modular enough that switching from one to the other is probably not an issue, and the alternative design could be easier for the CTFE engine's implementation, just not as nice to use for end users (without crates wrapping the logic)

One wart of this design that I'm fixing in separate branches is that `TypeId::info` will panic if used at runtime, while it should be uncallable