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.