Tracking issue for lazy type aliases

GuillaumeGomez commented 1 year ago

This is a tracking issue for the feature lazy type aliases. It's considered to be a “sophisticated bug fix” for #21903, hence no RFC. The feature gate for the issue is #![feature(lazy_type_alias)].

The feature implements the expected semantics for type aliases:

Where-clauses and bounds on type parameters of type aliases are enforced.
Type aliases are checked for well-formedness.
Where-clauses are trailing instead of leading just like they are for associated types.
Privacy: Private type aliases cannot be used in public signatures anymore, the type alias must also be made public (see also #114213).

It can only be stabilized as part of a new edition since the new semantics are incompatible with the status quo.

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

[x] Implement the feature (see Implementation history)
[ ] Address any open issues and drive the feature to completeness
[ ] Make the feature part of Rust 202X
[ ] Adjust documentation (see instructions on rustc-dev-guide)
[x] Formatting for new syntax has been added to the Style Guide (nightly-style-procedure)
- 114901
[ ] Stabilization PR (see instructions on rustc-dev-guide)

Unresolved questions

None.

Resolved questions

* We currently don't imply any outlives-bounds on lazy type aliases to prevent introducing unsoundness which as it stands implied bounds would theoretically bring along. With this in mind, when is the best time to add implied bounds to lazy type aliases? * [Zulip discussion][implied-bounds-zulip]. * T-lang consensus: This should be added before stabilization. * Further progress is tracked in [#118479](https://github.com/rust-lang/rust/issues/118479). * Implementation: [#119350](https://github.com/rust-lang/rust/pull/119350).

Implementation history

108860
112853
113201
113755
114228
114253
114566
114594
114662
117164
- Among other things, this PR impls proper orphan checking for lazy type aliases (more precisely, weak alias types)
119350
120556
120780
121344
126575

Honorable Mentions

97974

Thanks to @fmease for writing this description. :)

orhid commented 1 year ago

i think i found a bug with this feature, sorry if this is not the right place to report this. the following code compiles without the feature enabled, while with it the second to last line throws the error[E0207]: the type parameter 'A' is not constrained by the impl trait, self type, or predicates error:

#![feature(lazy_type_alias)]

struct Foo<A,B> {
    foo_a: A,
    foo_b: B,
}

type Faa<A> = Foo<A,A>;

// this one does not
impl<A> Faa<A> {}

// this one compiles
impl<A> Foo<A,A> {}

link to playground

fmease commented 1 year ago

@orhid Thanks for your report! Usually you just open a separate issue since a tracking issue is meant to record the overall progress on a feature and to be a hub for connecting to issues. No worries though, the issue description is a bit terse right now, I'm gonna update it later. I've opened #116100 for your issue.

CAD97 commented 9 months ago

Recording:

Trailing where clauses on top level type aliases are currently syntax-stable (i.e. allowed under an inactive #[cfg]), and is only feature gated semantically (i.e. after macro expansion).

For other unstable features that were accidentally allowed as syntax-stable (e.g. macro items), we now have the forward-compatibility warning unstable_syntax_pre_expansion (https://github.com/rust-lang/rust/issues/65860). We could potentially add this syntax into that machinery if we want to be conservative w.r.t. the unstable feature.

But on the other hand, trailing where is already allowed for associated types, so it being syntax stable for top level type aliases isn't particularly worrying or risky.

TL;DR: it being syntax stable deserves to be recorded, and is fine to remain such without any FCW (imo).

fmease commented 7 months ago

But on the other hand, trailing where is already allowed for associated types, so it being syntax stable for top level type aliases isn't particularly worrying or risky.

@CAD97, I might've misunderstood your comment but to me it seems like you think that trailing where-clauses are deprecated while it's actually leading where-clauses that are deprecated.

Trailing where-clauses are the new default for both associated types and lazy type aliases. Leading WCs on assoc tys are warned against and rejected on lazy ty aliases during semantic analysis. See #114662.

I forgot what the specific reason was for continuing to allow leading WCs syntactically but backward compatibility is likely the answer. See #89122 for more information.

CAD97 commented 7 months ago

For clarity, I was aware this was the case, and was just noting the syntactic stability had preceded the semantic stability in this case (and concluded this is fine given the stability of the same syntax for associated types). The mention of FCW is due to expectation but merely that it is unstable and could change.

rust-lang / rust