• Feature Name: Trait alias
  別名
• Start Date: 2016-08-31
• RFC PR: rust-lang/rfcs#1733
• Rust Issue: rust-lang/rust#41517

Summary

Traits can be aliased with the trait TraitAlias = …; construct.

Motivation

First motivation: impl

Sometimes, some traits are defined

#![allow(unused)]
fn main() {
pub trait Foo<T> {
  // ...
}
}

It’s not uncommon to do that in generic crates and implement

#![allow(unused)]
fn main() {
// in the backend crate
pub struct Backend;

impl Foo<Backend> for i32 {
  // ...
}
}

Users who want to use that crate will have to export both the trait Foo from the generic crate and the backend singleton type from the backend crate. Instead, we would like to be able to leave the backend singleton type hidden in the crate. The first shot would be to create a new trait for our backend:

#![allow(unused)]
fn main() {
pub trait FooBackend: Foo<Backend> {
  // ...
}

fn use_foo<A>(_: A) where A: FooBackend {}
}

If you try to pass an object that implements

#![allow(unused)]
fn main() {
impl<T> FooBackend for T where T: Foo<Backend> {}
}

With that, it’s now possible to pass an object that implements

Second example: ergonomic collections and scrapping boilerplate

Another example is associated

#![allow(unused)]
fn main() {
pub trait Service {
  type Request;
  type Response;
  type Error;
  type Future: Future<Item=Self::Response, Error=Self::Error>;
  fn call(&self, req: Self::Request) -> Self::Future;
}
}

It would be nice to be able to create a few aliases

#![allow(unused)]
fn main() {
Service<Request = http::Request, Response = http::Response, Error = http::Error>;
}

The trait above is a http service trait which only the associated

Detailed design

設計（する）

Syntax

文法

Declaration

宣言

The syntax

#![allow(unused)]
fn main() {
trait TraitAlias = Trait;
}

Trait aliasing

#![allow(unused)]
fn main() {
trait DebugDefault = Debug + Default;
}

Optionally, if needed, one can provide a where clause

#![allow(unused)]
fn main() {
trait DebugDefault = Debug where Self: Default; // same as the example above
}

Furthermore, it’s possible to use only the where clause

#![allow(unused)]
fn main() {
trait DebugDefault = where Self: Debug + Default;
}

It’s also possible to partially bind associated

#![allow(unused)]
fn main() {
trait IntoIntIterator = IntoIterator<Item=i32>;
}

This would leave IntoIntIterator with a free parameter

#![allow(unused)]
fn main() {
fn foo<I>(int_iter: I) where I: IntoIntIterator<IntoIter = std::slice::Iter<i32>> {}
}

A trait alias

#![allow(unused)]
fn main() {
trait LifetimeParametric<'a> = Iterator<Item=Cow<'a, [i32]>>;`

trait TypeParametric<T> = Iterator<Item=Cow<'static, [T]>>;
}

Specifically,

ATTRIBUTE* VISIBILITY? trait IDENTIFIER(<GENERIC_PARAMS>)? = GENERIC_BOUNDS (where PREDICATES)?;

GENERIC_BOUNDS is a list

Use semantics

You cannot directly

It is an error to attempt to override a previously specified

#![allow(unused)]
fn main() {
trait SharableIterator = Iterator + Sync;
trait IntIterator = Iterator<Item=i32>;

fn quux1<T: SharableIterator<Item=f64>>(...) { ... } // ok
fn quux2<T: IntIterator<Item=i32>>(...) { ... } // ok (perhaps subject to lint warning)
fn quux3<T: IntIterator<Item=f64>>(...) { ... } // ERROR: `Item` already constrained

trait FloIterator = IntIterator<Item=f64>; // ERROR: `Item` already constrained
}

When using a trait alias

1. it contains
   含む
   an object safe trait, optionally a lifetime, and zero or more of these other bounds:
   制限する、結び付けられて
   Send, Sync (that is, trait Show = Display + Debug; would not be object safe);
2. all the associated
   関連付けられた
   types of the trait need to be specified;
   特定する、指定する、規定する
3. the where clause,
   句、節
   if present,
   ある
   only contains
   含む
   bounds
   制限する、結び付けられて
   on Self.

Some examples:

#![allow(unused)]
fn main() {
trait Sink = Sync;
trait ShareableIterator = Iterator + Sync;
trait PrintableIterator = Iterator<Item=i32> + Display;
trait IntIterator = Iterator<Item=i32>;

fn foo1<T: ShareableIterator>(...) { ... } // ok
fn foo2<T: ShareableIterator<Item=i32>>(...) { ... } // ok
fn bar1(x: Box<ShareableIterator>) { ... } // ERROR: associated type not specified
fn bar2(x: Box<ShareableIterator<Item=i32>>) { ... } // ok
fn bar3(x: Box<PrintableIterator>) { ... } // ERROR: too many traits (*)
fn bar4(x: Box<IntIterator + Sink + 'static>) { ... } // ok (*)
}

The lines marked with (*) assume

Ambiguous constraints

制約

If there are multiple

#![allow(unused)]
fn main() {
trait Foo { type Assoc; }
trait Bar { type Assoc; } // same name!

// This works:
trait FooBar1 = Foo<Assoc = String> + Bar<Assoc = i32>;

// This does not work:
trait FooBar2 = Foo + Bar;
fn badness<T: FooBar2<Assoc = String>>() { } // ERROR: ambiguous associated type

// Here are ways to workaround the above error:
fn better1<T: FooBar2 + Foo<Assoc = String>>() { } // (leaves Bar::Assoc unconstrained)
fn better2<T: FooBar2 + Foo<Assoc = String> + Bar<Assoc = i32>>() { } // constrains both
}

Teaching

Traits are obviously a huge prerequisite. Traits aliases

Conceptually, a trait alias

• as a bound
  制限する、結び付けられて
  : exactly
  正確に
  like a trait, a trait alias
  別名
  can be used to constraint
  制約
  a type (type parameters
  仮引数
  list,
  リスト、列挙する
  where-clause)
• as a trait object: same thing as with a trait, a trait alias
  別名
  can be used as a trait object if it fits object safety restrictions
  制限
  (see above in the semantics section)
• in an impl Trait

Examples should be showed for all of the three cases above:

As a bound

制限する、結び付けられて

#![allow(unused)]
fn main() {
trait StringIterator = Iterator<Item=String>;

fn iterate<SI>(si: SI) where SI: StringIterator {} // used as bound
}

As a trait object

#![allow(unused)]
fn main() {
fn iterate_object(si: &StringIterator) {} // used as trait object
}

In an impl Trait

#![allow(unused)]
fn main() {
fn string_iterator_debug() -> impl Debug + StringIterator {} // used in an impl Trait
}

As shown above, a trait alias

#![allow(unused)]
fn main() {
pub trait Service {
  type Request;
  type Response;
  type Error;
  type Future: Future<Item=Self::Response, Error=Self::Error>;
  fn call(&self, req: Self::Request) -> Self::Future;
}

trait HttpService = Service<Request = http::Request, Response = http::Response, Error = http::Error>;

trait MyHttpService = HttpService<Future = MyFuture>; // assume MyFuture exists and fulfills the rules to be used in here
}

Drawbacks

• Adds another construct

  作る、構成体
  to the language.
  言語

• The syntax

  文法
  trait TraitAlias = Trait requires lookahead in the parser to disambiguate a trait from a trait alias.
  別名

Alternatives

代わりのもの、選択肢

Should we use type as the keyword instead of trait?

type Foo = Bar; already creates an alias

If we used type for the keyword, this would imply that Foo could also be used as a bound

However, this mixes the concepts of types and traits, which are different, and allows

Supertraits & universal impl

It’s possible to create a new trait that derives the trait to alias,

#![allow(unused)]
fn main() {
trait Foo {}

trait FooFakeAlias: Foo {}

impl<T> Foo for T where T: FooFakeAlias {}
}

This works for trait objects and trait bounds

There’s currently no alternative

ConstraintKinds

Similar

Syntax

文法

for sole where clause.

句、節

The current RFC specifies

#![allow(unused)]
fn main() {
trait DebugDefault = where Self: Debug + Default;
}

This is one of many syntaxes

• trait DebugDefault where Self: Debug + Default; (which has been considered
  みなす、考慮する
  and discarded
  捨てる
  because it might look too much like a new trait definition)
• trait DebugDefault = _ where Self: Debug + Default; (which was considered
  みなす、考慮する
  and then removed because it is technically unnecessary)
• trait DebugDefault = Self where Self: Debug + Default; (analogous to previous
  前の
  case but not formally discussed)

Unresolved questions

Trait alias

別名

containing

含む

only lifetimes

This is annoying. Consider:

#![allow(unused)]
fn main() {
trait Static = 'static;

fn foo<T>(t: T) where T: Static {}
}

Such an alias

If we chose another keyword, like constraint

Which bounds

制限する、結び付けられて

need to be repeated when using a trait alias?

RFC 1927 intends to change the rules here for traits, and we likely want to have the rules for trait aliases

The constraint

What about bounds

制限する、結び付けられて

on type variable

変数、ストレージ

declaration

宣言

in the trait alias?

#![allow(unused)]
fn main() {
trait Foo<T: Bar> = PartialEq<T>;
}

PartialEq has no super-trait Bar, but we’re adding

#![allow(unused)]
fn main() {
trait Foo<T> = where Self: PartialEq<T>, T: Bar;
}

Issue 21903 explains the same problem for type aliasing.

Note: what about the following proposal below?

When using a trait alias

#![allow(unused)]
fn main() {
trait Foo<T: Bar> = PartialEq<T>;
}

Here, T adds a Bar bound.

#![allow(unused)]
fn main() {
trait Bar<T> = PartialEq<T: Bar>;
}

Currently, we don’t have a proper understanding of that situation, because we’re adding

#![allow(unused)]
fn main() {
trait BarPrecond<T> where T: Bar = PartialEq<T>;
trait BarImplic<T> = PartialEq<T> where T: Bar;
trait BarImpossible<T> where T: Bar = PartialEq<T> where T: Bar;
}

BarPrecond would require the use-site code to fulfil the constraint,

#![allow(unused)]
fn main() {
fn foo<A, T>() where A: BarPrecond<T>, T: Bar {}
}

BarImplic would give us T: Bar:

#![allow(unused)]
fn main() {
fn foo<A, T>() where A: BarImplic<T> {
  // T: Bar because given by BarImplic<T>
}
}

BarImpossible wouldn’t compile because we try to express a pre-condition and an implication for the same bound

#![allow(unused)]
fn main() {
trait BarBoth<T> where T: Bar = PartialEq<T> where T: Debug;

fn foo<A, T>() where A: BarBoth<T>, T: Bar {
  // T: Debug because given by BarBoth
}
}