Tracking Issue for reflection

[oli-obk]

This is a tracking issue for an un-RFC-ed language feature experiment
The feature gate for the issue is #![feature(reflection)].

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 an MVP (@oli-obk will do so)
• Discuss with 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 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?)

Implementation history

• first (not salvageable) prototype: https://rust-lang.zulipchat.com/#narrow/channel/427678-t-lang.2Finterop/topic/type.20layout.20import.2Fexport/near/505722852