# Pre-RFC: Runtime reflection **URL:** \ **Category:** language design\ **Created:** [October 2, 2019, 8:20am UTC](https://internals.rust-lang.org/t/pre-rfc-runtime-reflection/11039 "2019-10-02T08:20:30Z")\ **Posts on this page:** 1\ **Showing post:** 8
**Author:** ![Ixrec](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ixrec/32/6754_2.png) [@Ixrec](https://internals.rust-lang.org/u/Ixrec)\ **Post date:** [October 2, 2019, 3:02pm UTC](https://internals.rust-lang.org/t/pre-rfc-runtime-reflection/11039/8 "2019-10-02T15:02:32Z")
> [@krojew](#): > > Macros/attributes create a very tight coupling between domain entities and a concrete crate which provides those. Such mixing of concerns is not good from a design standpoint, with various levels of resulting problems. Runtime reflection, while admittedly heavy, solves this problem by acting as an intermediate between the domain and the user. This is a perfect example of why digging into specific, concrete examples is absolutely vital for a proposal like this: overly abstract arguments can be plausibly pointed in any direction. To me, the proc macro API (plus the de facto standard `syn` and `quote` crates) already provide the decoupling intermediary we need for compile-time reflection. So without any further details, the fact that diesel has its own proc macro doesn't seem any more problematic than the fact that diesel would have its own reflection function you'd have to invoke if it used runtime reflection instead. Bringing up aspect-oriented programming was probably the most concrete thing I did see. Although I have only a vague awareness of AoP, the people I've talked to who've used it mostly provide stories of incomprehensible configuration regularly leading to indecipherable startup errors. In contrast, your posts appear to be suggesting that not supporting AoP is a serious design flaw of the language. I don't know who's right, but if the utility of this feature proposal rests on AoP use cases, there definitely needs to be some effort spent fleshing out the AoP use cases that you want Rust to support, for those of us who aren't already familiar with and supportive of them. (you mention a "provided example" in your post, but unfortunately I have no idea what this is referring to; I only see a reflection API sketch in the OP) > [@krojew](#): > > My argument is not to replace existing solutions, but to provide an alternative which is used with success in other languages. Having the possibility to use advanced concepts with the safety guarantees and performance of Rust looks very appealing in my opinion. It's probably worth noting that "reflection" plus "safety guarantees and performance" is almost certainly going to end up meaning _compile-time_ reflection instead of runtime reflection. After all, most of Rust's magic is compile-time magic; at runtime it's doing the same stuff as every other AoT-compiled language (except the "pull-based" futures I guess?). AFAIK, the major "other languages" that use runtime reflection today do so not because there are any use cases where runtime is better, but either because they don't have a compile time at all, or because they prioritize flexibility over performance, or because they're managed languages which already have other reasons for paying the price of keeping type metadata around at runtime, so "just" exposing it to the language isn't as big of a deal. Is that not true for whatever language you're thinking of? --- _[View the full topic](https://internals.rust-lang.org/t/pre-rfc-runtime-reflection/11039)._