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

Tracking issue for trait alias implementation (RFC 1733) #55628

Open
3 tasks done
nikomatsakis opened this issue Nov 2, 2018 · 4 comments
Open
3 tasks done

Tracking issue for trait alias implementation (RFC 1733) #55628

nikomatsakis opened this issue Nov 2, 2018 · 4 comments
Labels
A-traits Area: Trait system B-RFC-implemented Blocker: Approved by a merged RFC and implemented. B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. S-tracking-needs-summary Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation. S-types-deferred Status: Identified as a valid potential future enhancement that is not currently being worked on T-types Relevant to the types team, which will review and decide on the PR/issue.

Comments

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Nov 2, 2018

This is the tracking issue for implementing (not discussing the design) RFC rust-lang/rfcs#1733. It is a subissue of #41517.

Current status

Once #55101 lands, many aspects of trait aliases will be implemented. However, some known limitations remain. These are mostly pre-existing limitations of the trait checker that we intend to lift more generally (see each case below for notes).

Well-formedness requirements. We currently require the trait alias to be well-formed. So, for example, trait Foo<T: Send> { } trait Bar<T> = Foo<T> is an error. We intend to modify this behavior as part of implementing the implied bounds RFC (#44491).

Trait object associated types. If you have trait Foo = Iterator<Item =u32>, you cannot use the trait object type dyn Foo. This is a duplicate of #24010.

Trait object equality. If you have trait Foo { } and trait Bar = Foo, we do not currently consider dyn Foo and dyn Bar to be the same type. Tracking issue #55629.

Pending issues to resolve

Deviations and/or clarifications from the RFC

This section is for us to collect notes on deviations from the RFC text, or clarifications to unresolved questions.

PR history

Other links

@alexreg
Copy link
Contributor

alexreg commented Nov 2, 2018

Good summary. Thanks for writing this up.

@eddyb
Copy link
Member

eddyb commented Nov 4, 2018

Have we considered blocking stabilization on lazy normalization?
That is, I'm worried that these are equivalent problems:

trait Foo<X> {}

type Bar<X: ExtraBound> = dyn Foo<X>;
fn bad<X>(_: &Bar<X>) {}

trait Foo2<X: ExtraBound> = Foo<X>;
fn bad2<X>(_: &dyn Foo2<X>) {}

The alternative, to consider Foo2 its own trait, has its own issues, IMO.

@alexreg
Copy link
Contributor

alexreg commented Feb 28, 2019

@eddyb Actually, they're not, under the current implementation, which is nice. The X: ExtraBound bound is enforced. Example.

@alexreg
Copy link
Contributor

alexreg commented Feb 28, 2019

@nikomatsakis I just realised you never got around to factoring out the part of my old PR #55994 that banned multi-trait objects via trait aliases... did you still want to tackle that?

@jonas-schievink jonas-schievink added B-unstable Blocker: Implemented in the nightly compiler and unstable. B-RFC-implemented Blocker: Approved by a merged RFC and implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. A-traits Area: Trait system labels Mar 23, 2019
@wesleywiser wesleywiser added WG-traits Working group: Traits, https://internals.rust-lang.org/t/announcing-traits-working-group/6804 S-tracking-needs-summary Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation. labels Jun 24, 2022
@lcnr lcnr added S-types-deferred Status: Identified as a valid potential future enhancement that is not currently being worked on T-types Relevant to the types team, which will review and decide on the PR/issue. and removed WG-traits Working group: Traits, https://internals.rust-lang.org/t/announcing-traits-working-group/6804 labels Jul 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-traits Area: Trait system B-RFC-implemented Blocker: Approved by a merged RFC and implemented. B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. S-tracking-needs-summary Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation. S-types-deferred Status: Identified as a valid potential future enhancement that is not currently being worked on T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants