RFC: Remove reflection from the compiler

[alexcrichton]

• Remove reflection from the compiler
• Remove libdebug
• Remove the Poly format trait as well as the :? format specifier

Rendered

[mahkoh]

You're suggesting removing an opt-in feature because of disadvantages that appear only when you opt-in? I don't see a replacement for :? debugging either.

[zwarich]

I'm in favor of this. The current reflection design greatly limits parametric reasoning. While features like unsafe blocks will always pose a problem in this regard, it seems best to keep them to a minimum.

[aturon]

@zwarich parametricity will fail even if we remove reflection, though, due to the way that Any is implemented. See this comment, and the IRC discussion starting here.

Typecase is well-known to violate parametricity but not soundness, and as @eddyb pointed out in the IRC discussion it's possible, without even using Any, to discover the size of a generic type by use of immutable references.

All that said, I certainly am in favor of removing this kind of reflection, due to the bloat and maintenance burden it causes.

[alexcrichton]

@mahkoh, as @aturon mentioned there is a nontrivial maintenance burden with this infrastructure, as well as a nontrivial API surface area which would need stabilization, maintenance, or consideration. At this point it's uncertain if the current reflection system is desirable moving into the future or whether it's the design we'd like moving into the future, and it's easiest to remove it for now and start from scratch with the knowledge of what we've learned in the past.

[eddyb]

@mahkoh it has become quite useless over time, almost any indirection breaks it (since it knows nothing of smart pointers and containers).

@zwarich more importantly IMO, this kind of "reflection" that we have allows breaking encapsulation, as it exposes private details from safe code.

cc @thestinger

[pnkfelix]

There might be utility in the reflection library that we could salvage for GC. But honestly I don't have much concrete evidence that such usage would make libdebug pull its weight.

[nrc]

I support this because it is a real wart on the compiler, it would simplify it a lot to remove reflection.

However, I do think we should have something to replace it (Show + deriving is mostly good enough, but not quite), preferably before we remove reflection.

Some ideas for a replacement: we need multiple ways to get a string representation - sometimes you do want to see the length, capacity, and a pointer for a vector, not the contents. We also need some way to guarantee we have a representation - perhaps we could have a compiler flag or something which always derives 'Show' for every data type in every crate (we wouldn't want this on by default due to the code bloat, I guess) - the nice thing about {:?} is that it always works.

[thestinger]

I think removing the old reflection features would be great. The API poorly designed and the implementation has undefined behaviour. The debug info support is nice enough that I don't see the point in having an API like this around. It's already possible to walk the representations of built-in types using gdb and the included pretty printing plugin. The pretty printing plugin can also be taught about the standard library types while there's no sane way to do that here.

There are other reflections features in the language like type_id / Any but this is the biggest elephant in the room. I think a good way of dealing with type_id would be having it require a Reflect bound, and dealing with that in the same way as Send.

Some ideas for a replacement: we need multiple ways to get a string representation - sometimes you do want to see the length, capacity, and a pointer for a vector, not the contents. We also need some way to guarantee we have a representation - perhaps we could have a compiler flag or something which always derives 'Show' for every data type in every crate (we wouldn't want this on by default due to the code bloat, I guess) - the nice thing about {:?} is that it always works.

That's provided via the core::raw module. It has struct types mapping to the internal representations of the built-in types. There's no backwards compatibility guarantee at the moment of course.

[pythonesque]

In favor of this. It's barely used anywhere anyway.

[brson]

Accepted. Discussion. Tracking.

[bvssvni]

We use TypeId and the name field on TyDesc in Piston to help debugging generic event programming where we rely on runtime reflection and compiler optimization to overcome inherent limitations in Rust's type system. It lets us overcome a problem where we don't have to specify generic constraints for all event traits, but use one GenericEvent to allow extending with new types of events.

I would like to have a way of getting type id and type desc for concrete types as a minimum reflection support. The first thing is to have a unique id for a concrete type, which makes it easy to use compiler optimized runtime reflection. The second is to give a nice error message when the contract of the runtime checked reflection is broken.

[huonw]

@bvssvni for clarity, this doesn't touch TypeId.