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

the reflection story is not settled so Any and the downcast method on Box<T> should not be stable #18005

Closed
thestinger opened this issue Oct 13, 2014 · 4 comments

Comments

@thestinger
Copy link
Contributor

It may be that we want to have reflection behind a type bound like Reflect, so reasoning about generics is possible from the type bounds. Removing most reflection support is the subject of an RFC: rust-lang/rfcs#379 and changing type_id has been part of that discussion.

@thestinger thestinger changed the title the reflection story is not settled so Any should not be stable the reflection story is not settled so Any and the downcast method on Box<T> should not be stable Oct 13, 2014
@pnkfelix
Copy link
Member

The decision to stabilize Any was not made lightly. It is a useful library, and it is not clear what the concrete benefits would be of offering formal parametricity in Rust (which is what the current design and implementation of Any is breaking, at least as I understand it).

Since there are useful libraries in the wild that use this, we plan to leave Any and downcast as stable.

Closing.

@pnkfelix pnkfelix reopened this Oct 16, 2014
@aturon
Copy link
Member

aturon commented Oct 16, 2014

Note that we could consider an RFC for a more restricted way to implement Any, and would probably be willing to take a patch for it, but can't commit resources to it without a more concrete motivating problem.

I want to reiterate that #[stable] interacts with semver, and every version before 1.0 is considered a major release, which permits stable APIs to change (though obviously this shouldn't happen often). The attributes are being used to track the stabilization process and note problems that need to be resolved by 1.0.

@thestinger
Copy link
Contributor Author

@pnkfelix: If 1.0 is going to be released in a few months, Rust won't be able to have parametric polymorphism or provide stable ABI due to type_id. The ability to reason about generic code and perform high-level optimizations via rewrite rules is useful. The lack of parametricity is why function merging (type_use) needed to be removed and type ids are a big problem for incremental compilation / stable ABIs because nearly any internal change can alter them.

@aturon
Copy link
Member

aturon commented Oct 16, 2014

Note that when Any was stabilized, the ability to get the type_id was hidden. But the new privacy rules made it impossible to hide the method.

We are considering making TypeId completely opaque from the public point of view. This should alleviate ABI concerns, though since Any would still provide downcasting it would clearly still violate parametricity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants