Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Remove reflection from the compiler #379

Merged
merged 1 commit into from Oct 14, 2014

Conversation

alexcrichton
Copy link
Member

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

Rendered

@mahkoh
Copy link
Contributor

mahkoh commented Oct 9, 2014

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
Copy link

zwarich commented Oct 9, 2014

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
Copy link
Member

aturon commented Oct 9, 2014

@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
Copy link
Member Author

@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
Copy link
Member

eddyb commented Oct 9, 2014

@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
Copy link
Member

pnkfelix commented Oct 9, 2014

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
Copy link
Member

nrc commented Oct 9, 2014

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.

@alexcrichton alexcrichton self-assigned this Oct 9, 2014
@thestinger
Copy link

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
Copy link
Contributor

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

@brson brson merged commit ecdd086 into rust-lang:master Oct 14, 2014
@brson
Copy link
Contributor

brson commented Oct 14, 2014

Accepted. Discussion. Tracking.

@bvssvni
Copy link

bvssvni commented Oct 15, 2014

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
Copy link
Member

huonw commented Oct 15, 2014

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

@alexcrichton alexcrichton deleted the remove-reflection branch October 15, 2014 19:11
@Centril Centril added A-reflection Proposals relating to compile time reflection. A-typesystem Type system related proposals & ideas A-parametricity Proposals relating to parametricity. A-machine Proposals relating to Rust's abstract machine. and removed A-reflection Proposals relating to compile time reflection. labels Nov 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-machine Proposals relating to Rust's abstract machine. A-parametricity Proposals relating to parametricity. A-typesystem Type system related proposals & ideas
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet