Allow `type` to create an alias for several trait bounds

[huonw]

e.g.

trait Foo {}
trait Bar {}


type Alias = Foo + Bar;

// typechecks fine:

fn bar<T: Foo + Bar>(t: T) {
    baz(t)
} 
fn baz<T: Alias>(t: T) {
    bar(t)
}

This is similar to defining a trait inheriting from both (trait Alias: Foo + Bar {}) but it's purely a synonym and doesn't have to be impl'd separately.

[glaebhoerl]

This is a subset of GHC's ConstraintKinds extension, and so also related to higher-kinded generics.

[huonw]

It is, but only very weakly; the proposal here is literally just a synonym to make code shorter/nicer, so this could even be implemented via textual substitution, modulo scoping concerns (although this obviously shouldn't be the actual implementation).

[glaebhoerl]

If you write type Foo = Bar I think you'd need some kind of kind inference at some point to figure out if it's a type or a trait.

[huonw]

The syntax could easily be something like trait type Foo = Bar. Thinking about it now, I'm not sure how different this would be from:

trait FooBar: Foo + Bar {}
impl<T: Foo + Bar> FooBar for T {}

other than the fact that these generic impls are slightly buggy. I guess a macro that expands to the above (assuming that pattern works) would be a solution.

(And the kind "inference" could just be checking that Foo is valid at the place it is used at those places.)

[glaebhoerl]

In Haskell the two are indeed equivalent. (Modulo ability to partially apply them which is another higher-kinded generics thing Rust doesn't have.)

[bblum]

reusing the type keyword for this would be confusing, as it's not a type at all. perhaps we could have a kind keyword.

[glaebhoerl]

It is a type, just of a different kind ;), which is not first-class in Rust. Anyway I think the nicest syntax would be:

trait FooBar = Foo + Bar

(but if generic impl bugs can be worked out there's probably not a pressing need)

[catamorphism]

I don't see a compelling need for this, since you can just declare another empty trait that inherits from both. I realize it's somewhat more concise if you have the additional syntax, but it just doesn't seem to add enough value to justify adding a new feature. Closing.

[mitchmindtree]

@catamorphism I think this would be handy for traits that have a number of type parameters i.e.

type InputNode = AudioNode<OutputBuffer, OutputSample>;

With this I imagine you could write

impl InputNode for Synth {}

whereas simply deriving from AudioNode<OutputBuffer, OutputSample> would require you to impl both InputNode and AudioNode<OutputBuffer, OutputSample>, right?

I'm not sure about using the type keyword though. Could we just use trait? i.e.

trait InputNode = AudioNode<OutputBuffer, OutputSample>;

[emk]

I also would love to be able to write:

pub trait DuktapeEncodable = Encodable<Encoder, DuktapeError>;

The workaround is simple enough, fortunately:

pub trait DuktapeEncodable: Encodable<Encoder, DuktapeError> {}
impl<T: Encodable<Encoder, DuktapeError>> DuktapeEncodable for T {}

[jonysy]

Similar to @emk's case, I'd love to be able to write:

pub trait Blas = Vector<f32> + Vector<f64> + MatrixVector<f32> ...

instead of:

pub trait Blas: Vector<f32> + Vector<f64> + MatrixVector<f32> ... { }

impl<I: Vector<f32> + Vector<f64> + MatrixVector<f32> ...> Blas for I { } 

The first example is clear. The second, not so much.. @catamorphism will you consider reopening this issue?

[jonysy]

@catamorphism another example (leaf)..

[jonysy]

Ignore my comments. RFC#1733 is moving in this direction.