Proposal: Change syntax of where clauses on type aliases

[nikomatsakis]

Source

Summary

Proposed: to alter the syntax of where clauses on type aliases so that they appear after the value:

type StringMap<K> = BTreeMap<K, String>
where
    K: PartialOrd

This applies both in top-level modules and in trats (associated types, generic or otherwise).

Background

The current syntax for where to place the "where clause" of a generic associated types is awkward. Consider this example (playground):

trait Iterable {
    type Iter<'a> where Self: 'a;

    fn iter(&self) -> Self::Iter<'_>;
}

impl<T> Iterable for Vec<T> {
    type Iter<'a>
    where 
        Self: 'a = <&'a [T] as IntoIterator>::IntoIter;

    fn iter(&self) -> Self::Iter<'_> {
        self.iter()
    }
}

Note the impl. Most people expect the impl to be written as follows (indeed, the author wrote it this way in the first draft):

impl Iterable for Vec<T> {
    type Iter<'a>  = <&'a [T] as Iterator>::Iter
    where 
        Self: 'a;

    fn iter(&self) -> Self::Iter<'_> {
        self.iter()
    }
}

However, this placement of the where clause is in fact rather inconsistent, since the = <&'a [T] as Iterator>::Iter is in some sense the "body" of the item.

The same current syntax is used for where clauses on type aliases (playground):

type Foo<T> where T: Eq = Vec<T>;

fn main() { }

Top-level type aliases

Currently, we accept where clauses in top-level type aliases, but they are deprecated (warning) and semi-ignored:

type StringMap<K> where
    K: PartialOrd
= BTreeMap<K, String>

Under this proposal, this syntax remains, but is deprecated. The newer syntax for type aliases (with where coming after the type) would remain feature gated until such time as we enforce the expected semantics.

Alternatives

Keep the current syntax.

In this case, we must settle the question of how we expect it to be formatted (surely not as I have shown it above).

impl<T> Iterable for Vec<T> {
    type Iter<'a> where Self: 'a 
        = <&'a [T] as IntoIterator>::IntoIter;

    fn iter(&self) -> Self::Iter<'_> {
        self.iter()
    }
}

Accept either

What do we do if both are supplied?

[nikomatsakis]

@rfcbot fcp merge

@jackh726 and I have discussed this issue and we both agree that changing the syntax here would be correct. I propose that we go ahead and do it.

[rfcbot]

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:

• @cramertj
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm

Concerns:

• do-we-want-to-make-this-change (Proposal: Change syntax of where clauses on type aliases #89122 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[cramertj]

Interesting! I can see why this would be desirable-- the formatting can work out a bit nicer in the new version, and it helps front-load the most important part of the alias (that is, it visually defers the bound until after the main part of the alias has been stated). However, I see two advantages to the previous approach:

1. It's simpler to copy-paste bounds from the trait definition to the impl. trait Foo { type Bar where X: Y; } -> impl Foo for X { type Bar where X: Y = ...; } both match up visually, and one can create an impl by merely copy-pasting the trait definition and adding the appropriate = .... I appreciate this symmetry, and it would be surprising to me if this were not supported, or if I was given a warning.
2. Conceptually, the bound is applying to the way the type alias may be used as stated in the trait definition. That is, the bound is not a property specific to the impl. This makes it more similar to the type signature of a trait method than the body of a trait method. Based on this, I'd expect it to belong on the left-hand side of the =. Trait definition / requirements first / on the left, followed by specifics of the impl is a useful pattern to keep, I think.

I don't think I feel particularly strongly either way, but the reasons above contribute to my initial preference for the old syntax.

[shepmaster]

@estebank pointed out to me that the parser might end up parsing both forms anyway, in order to provide useful diagnostics.

[nikomatsakis]

Yes, I expect the parser to parse both forms and offer useful tips for how to transform from one to the other.

[joshtriplett]

FWIW, I can see why the type ... where ... = ... syntax would make sense as well, since it seems analogous to fn ...() where ... { ... }. I do think the proposed change feels more likely to produce readable code, though. On balance, I'd expect a where to get more complex than the RHS of the =.

[camelid]

Note also that trailing where clauses are supported for tuple structs:

// Compiles successfully.
pub struct Struct<T>(T)
where
    T: Eq;

[petrochenkov]

@estebank pointed out to me that the parser might end up parsing both forms anyway, in order to provide useful diagnostics.

I think this is the way to go.
If this proposal is accepted, then we'll need to support where clauses in both positions anyway due to compatibility.
In that case why not return a non-fatal error in one of the cases, and normalize legal syntax to the single already existing form.

Most people expect the impl to be written as follows

What makes you think so?
In functions where clauses are between the header and the body, why in types it should be after the "body"?

In trait aliases, which have similar syntax with =, where is actually a part of the "body".
Will it use a second where for where clauses?

trait Alias = Body1 where Self: Body2 where NotABodyAnymore;

?

[nikomatsakis]

What makes you think so?

A fair question! Anecdotal reports. It's hard to quantify this, perhaps I should rewrite to "many people". We could try to get more precise about this, perhaps via a survey.

In that case why not return a non-fatal error in one of the cases, and normalize legal syntax to the single already existing form.

e.g., via rustfmt? That is an option, yes. We could simply union where clauses in the two positions.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[cramertj]

Ah-- I made a procedural mistake and did not file a concern. I assume we're still considering this pending further discussion?

@rfcbot concern do-we-want-to-make-this-change

[nikomatsakis]

We discussed this in our @rust-lang/lang meeting today. There wasn't a clear consensus one way or the other.

Some points we identified:

There are plenty of cases in Rust's existing grammar where where clauses follow types:

fn foo() -> T
where ...
{ }

impl Foo for Bar
where ...
{}

Therefore, there isn't really a concern about introducing new grammatical ambiguities (this was raised as a concern in the meeting).

One thing we did find is that, when reading type Foo = Bar where Baz, Some people mentally "group" the where clause with Bar, and some mentally group it with Foo. Note that, in all existing instances, where clauses are attached to the surrounding item.

We discussed whether changes to the formatting rules might help, but we didn't discuss that very much.

[estebank]

Third option: support both 😬

We have to support both in the parser for diagnostics, what if we just... accepted both ways?

[thorjelly]

I personally feel as though type Foo<T> = Bar<T> where T: ... is semantically equivalent to fn foo<T>() -> Bar<T> where T: ... and impl Foo<T> for Bar<T> where T: ..., where in each case =, ->, and for sort of act as operators on Foo and Bar. Therefore, I feel like the new proposal is most consistent with the syntax people are most used to.

This is coming from someone who has barely used the current implementation of GATs, so I am unused to its syntax, I would find the new proposal a fair bit more intuitive.

[nikomatsakis]

@estebank I feel like supporting both without a real reason to support both is suboptimal. Then there will be confusion over whether there is a difference, for example, and perhaps two camps (one who prefers one, one who prefers the other). I don't mind more than one way to do things, but it feels like it needs strong justification to me.

One thing I would like is if rustfmt quietly changed from one to the other, though =) that would affect my opinion. But this isn't generally how rustfmt does things.

[dtolnay]

In the context of the FCP proposed in #89122 (comment), what behavior is proposed if where is given in both places?

type Thing<T> where T: IntoIterator = T::IntoIter
where
    T::Item: Clone;

Does this union the clauses, or does it reject? From the discussion above I'm unable to tell whether a concrete behavior was proposed. Asking as someone who will need to implement this in a Rust parser.

[dtolnay]

Separately, I feel that #89122 (comment) is going to require a response/consensus before completing the FCP.

Here is a concrete example to consider:

#![feature(trait_alias)]

trait Alias<T: Clone> = where T: Default;

// okay, equivalent to `where T: Clone + Default`
fn clone<T: Alias<T> + Clone>() {}

// ERROR, trait bound `T: Clone` not satisfied
fn default<T: Alias<T> + Default>() {}

In this situation, what is proposed to be the where equivalent of the T: Clone bound on Alias? Prior to this proposal, it's natural to expect that it would be:

trait Alias<T> where T: Clone = where T: Default;

This proposal throws a wrench in the works, as @petrochenkov called attention to. It would now seem to be the somewhat bizarre:

trait Alias<T> = where T: Default where T: Clone;

Relatedly, what does the following mean?

trait Alias<T> = Default
where
    T: Clone;

Is this equivalent to trait Alias<T: Clone> = Default, or to (the old interpretation of) trait Alias<T> = Default where T: Clone, which are not the same thing?

trait_alias is unstable (cc tracking issue #41517) but since the syntax is heavily inspired by type alias syntax, I think it's worth acknowledging the implications that type alias syntax changes would have on it, and maybe loop in people involved in that proposal if there are specific people.

[yasammez]

Third option: support both 😬

We have to support both in the parser for diagnostics, what if we just... accepted both ways?

This would be my least preferred option: if you support two variants for the same thing, any codebase of sufficient size will eventually contain both, no matter how strict you are trying to be. This increases the mental burden for developers trying to understand existing code and leads to needless discussions about which style to prefer within teams.

[nikomatsakis]

@petrochenkov

In trait aliases, which have similar syntax with =, where is actually a part of the "body".

Remind me, do trait aliases currently permit where clauses in both places?

[petrochenkov]

do trait aliases currently permit where clauses in both places?

Not right now, but both positions have a well-defined meaning in theory, as @dtolnay describes in #89122 (comment).