Tracking issue for trait aliases

[withoutboats]

This is a tracking issue for trait aliases (rust-lang/rfcs#1733).

TODO:

• Implement: tracking issue
• #56485 — Bringing a trait alias into scope doesn't allow calling methods from its component traits (done in #59166)
• #56488 — ICE with trait aliases and use items
• #57023 — Nightly Type Alias Compiler panic unexpected definition: TraitAlias
• #57059 — INCOHERENT_AUTO_TRAIT_OBJECTS future-compatibility warning (superseded by #56481)
• Document
• Stabilize

Unresolved questions:

• Are bounds on other input types than the receiver enforced or implied?

[durka]

I think #24010 (allowing aliases to set associated types) should be mentioned here.

[durka]

I'd like to take a crack at this (starting with parsing).

[carllerche]

I read the RFC and I saw a call out to Service, but I am not sure if the RFC actually solves the Service problem.

Specifically, the "alias" needs to provide some additional associated types:

See this snippet: https://gist.github.com/carllerche/76605b9f7c724a61a11224a36d29e023

Basically, you rarely want to just alias HttpService to Service<Request = http::Request> You really want to do something like this (while making up syntax):

trait HttpService = Service<http::Request<Self::RequestBody>> {
    type RequestBody;
}

In other words, the trait alias introduces a new associated type.

The reason why you can't do: trait HttpService<B> = Service<http::Request<B>> is that then you end up getting into the "the type parameter B is not constrained by the impl trait, self type, or predicates" problem.

[phaazon]

Basically, you rarely want to just alias HttpService to Service<Request = http::Request>

Rarely? How do you define that?

The syntax you suggest seems a bit complex to me and non-intuitive. I don’t get why we couldn’t make an exception in the way the “problem” shows up. Cannot we just hack around that rule you expressed? It’s not a “real trait”, it should be possible… right?

[carllerche]

@phaazon rarely with regards to the service trait. This was not a general statement for when you would want trait aliasing.

Also, the syntax was not meant to be a real proposal. It was only to illustrate what I was talking about.

[phaazon]

I see. Cannot we just use free variables for that? Like, Service<Request = http::Request> implies the free variable used in http::request<_>?

[carllerche]

@phaazon I don't understand this proposal.

[varkor]

@durka: how's the work on the follow-up to #45047 going?

[clarfon]

Something I mentioned in the RFC: trait Trait =; is accepted by the proposed grammar and I think that this is a bit weird. Perhaps maybe the proposed _ syntax might be more apt here, because I think that allowing empty trait requirements is useful.

[durka]

We can put a check for that in AST validation. However I suppose it could be useful for code generation if there's no special case, I dunno.

…

On Tue, Feb 27, 2018 at 12:48 PM, Clar Roʒe ***@***.***> wrote: Something I mentioned in the RFC: trait Trait =; is accepted by the proposed grammar and I think that this is a bit weird. Perhaps maybe the proposed _ syntax might be more apt here, because I think that allowing empty trait requirements is useful. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#41517 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC3n3HdG3ZOmbN2PKky7nFnx0WokY7Lks5tZD_fgaJpZM4NGzYc> .

[clarfon]

One other thing to note as a general weirdness is macro expansions involving trait bounds. Currently, fn thing<T:>() is valid syntax but perhaps fn thing<T: _>() should be the recommended version.

But then, is _ + Copy or something okay? I'm not sure. I would just suggest Any but that has different guarantees.

[petrochenkov]

Empty bound lists (and other lists) are accepted in other contexts as well, e.g. fn f<T: /*nothing*/>() { ... }, so trait Trait = /*nothing*/; being accepted is more of a rule than an exception.

[clarfon]

I think it makes sense being accepted, although I wonder if making it the canonical way to do so outside of macros is the right way to go. We already have been pushing toward '_ for elided lifetimes in generics, for example.

[ricochet1k]

Not sure if it is a known bug or not, but if you have a pub trait Asdf = Clone; or whatever, cargo fmt strips off the pub which can then cause errors about exposing a private Trait.

[alexreg]

@ricochet1k Best to file as an issue on the rustfmt repo. Thanks! https://github.com/rust-lang/rustfmt/issues

[topecongiro]

@ricochet1k @alexreg Thanks.

On a side note, currently putting auto in front of a trait alias is allowed:

#![feature(trait_alias)]
 
auto trait Foo = Iterator<Item = u8>;
 
fn main() {}

Is this intentional? If not, could we change this to a syntax error? FWIW putting unsafe in front of a trait alias is a syntax error.

[alexreg]

@topecongiro Definitely an oversight. Thanks for the report.

[seanmonstar]

Hit another ICE today reported in #59029

[davidbarsky]

Since #59166 landed, is it possible to mark the second item #56485 as complete and begin the documentation/stabilization process?

[alexreg]

@davidbarsky I don't think it's going to get stabilised quite yet... there are some outstanding questions about whether we want to generalise this system (mainly by other individuals).

[davidbarsky]

@alexreg Understood—when you say “we want to generalize this system” are you referring to the above discussion on higher-rank type bounds or something else?

(Apologies if I'm having you restate things that were clearly state earlier—I'm just entering this discussion for the first time and I didn't see anything in the above conversation about generalization beyond the HRTB-related discussion.)

[varkor]

@davidbarsky: I'm not sure whereabouts this is recorded, but there has been some concern about whether "bounds aliases" (i.e. the current behaviour for "trait aliases") or "constraint aliases" (where you explicitly parameterise over the type being bound) are the most useful notion of alias. For example, with trait aliases, you cannot encode type equality constraints (see #20041, for example).

As a separate, but related issue, there are learnability concerns about the naming convention. Namely, there are three related, but distinct concepts that could be considered "trait aliases":

• True trait aliases (which is technically not what the feature being tracked here is).
• Bounds aliases (this feature).
• Constraint aliases.

These questions at least will need to be resolved before stabilisation.

[Centril]

A 4th question is how this all integrates with "trait generics" and "associated traits" as well. My goal is to ensure that we end up with flexible & a coherent system for all of this. However, it is difficult to test this out without having associated traits & trait generics on nightly. Thus, I think stabilization of this should wait on that.

[seanmonstar]

It'd be helpful to add steps of what's blocking this to the top comment, and if possible, links to something describing what they are. For instance, this is the first I've read about "associated traits". Are "trait generics" meant to describe generics on associated types (GATs)?

[Centril]

@seanmonstar e.g. fn foo<trait T>(...), foo::<Ord + Eq> and trait A { trait B; }. See https://github.com/Centril/rfc-trait-parametric-polymorphism/ for more (very WIP).

[seanmonstar]

@Centril woah! Very interesting idea...

Looking through the original trait aliases RFC, I see ContraintKinds listed as an alternative. Since it's listed, I assume it was discussed, and it didn't hold up the RFC merging. Has something come up since that reverts that decision?

[Centril]

@seanmonstar I just read through all of the comments in the RFC; ConstraintKinds as in having trait X universal quantification and as an associated item was barely discussed. bound vs. trait was discussed partially; I'm not sure I agree entirely with the rationale. constraint Foo<T> was discussed but I think we need to actually test the limits of the system with associated traits and trait generics to gain confidence in the solution. IOW: we need more data with a fully implemented and coherent system.

[seanmonstar]

ConstraintKinds as in having trait X universal quantification and as an associated item was barely discussed.

Ah, that's too bad. I'm a fan of keeping tracking issues to status updates, so would it make sense to move discussion of whether something like ConstraintKinds should block the progress here to something else? Like an IRLO thread or something?

[Centril]

@seanmonstar I don't think I have the time for such a discussion but go ahead if you want. My view is that there would need to be really good arguments why we should stabilize this before associated traits & such are even in nightly. Given that trait aliases are mostly a matter of ergonomics it all seems like quite a risky endeavor to me. As such I'm at least for now not inclined to put trait aliases on a clear path to stabilization.

[SimonSapin]

@Centril Trait parameters and associated traits sound potentially interesting but this is the first I hear of them. Are they on any roadmap? Is there consensus in the lang team that they should block existing features (with an accepted RFC and an implementation) like trait aliases, or is that your personal opinion?

[Centril]

Are they on any roadmap?

Nope.

is that your personal opinion?

Yep.

[varkor]

I think the stabilisation process includes consideration of interaction with possible future features, if insufficiently evaluated during the RFC process (and, indeed, I think some of these concerns were not realised until after the RFC was accepted). Besides that, though, there are issues with trait aliases that have been raised in the existing discussion (and which turn out to be relevant to @Centril's concerns).