Tracking Issue for type_info

This is a tracking issue for the project goal rust-lang/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

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 parameter T.
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?)
Should free functions be used rather than methods on existing types? Tracking Issue for type_info #146922 (comment)

Implementation history

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

Rollup merge of rust-lang#146923 - comptime-reflect, r=BoxyUwU

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

Rollup merge of rust-lang#151019 - type-of-unsized, r=oli-obk

Unrolled build for #161401 in rollup 161505

Rollup merge of #161401 - yara-blue:remove-typekind-fields2, r=oli-obk

Rollup merge of rust-lang#161896 - yara-blue:reflection-refactor-arra…

Rollup merge of rust-lang#162294 - yara-blue:reflection-refactor-ptrs…

Unrolled build for #162294 in rollup 162434

Rollup merge of rust-lang#161896 - yara-blue:reflection-refactor-arra…

Unrolled build for #161896 in rollup 162445

Rollup merge of #162294 - yara-blue:reflection-refactor-ptrs, r=oli-obk

unresolved question:
Should we turn the reflection methods into plain functions taking a TypeId as argument so we do not pollute TypeId and we can have a nicer API in the (far) future?

Context:
The entry point to reflection is methods on TypeId. For various reasons, we're making the API fine grained and targeted. We'll end up with a wide and shallow API with many methods on TypeId. This is not nice to use directly, however we intend for end-users to use an ergonomic wrapper crate. We'll ensure there is at least one of those. We're doing this for the usual reasons (1).

At some point, potentially many years in the future (2), the ecosystem may coalesce on a single nice ergonomic wrapper for all use cases. If we end up stabilizing a lot of reflection methods on TypeId any future API using TypeId as the entry point will have it's methods drowned out by the existing stable ones. Instead could keep TypeId "clean" at the cost of worse ergonomics now.

(1): faster iteration, more accessible to ppl outside the compiler, less code in the compiler, avoid stabilizing a nice API that turns out to be bad later etc etc.
(2): we may even have reflection synthesize new code at some point. That could very well change what an ergonomic API looks like.

Before stabilizing, we should consider what the methods querying doc comments should return. Would we want to merge and transform different doc comments together and/or beautify them?

It could look as follows:

#[doc = "first"]
/// second
/**   third
 *  forth
 */
struct A;

// using comment field out of DocComment
TypeId::of::<A>().docs() == ["first", " second", "   third\n *  forth\n "] 
// alternatively using rustc_resolve to apply transformations
TypeId::of::<A>().doc() == "first\nsecond\n third\n forth\n"

To me it seems to make sense to expose a slice of (non-transformed) str to keep the const time machine minimal

Rollup merge of rust-lang#165094 - Tess4552:reflection-type-id-docs, …

Navigation Menu

Repository navigation

Tracking Issue for type_info #146922

About tracking issues

Steps

Unresolved Questions

Implementation history

75 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for type_info #146922

Description

About tracking issues

Steps

Unresolved Questions

Implementation history

Activity

75 remaining items

yara-blue commented on Oct 27, 2026

Tess4552 commented on Oct 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions