Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trait alias. #1733

Merged
merged 30 commits into from
Apr 24, 2017
Merged
Changes from 2 commits
Commits
Show all changes
30 commits
Select commit Hold shift + click to select a range
55de6a3
Trait alias.
hadronized Aug 31, 2016
c0c4834
Updated the proposal according to the discussion in #1733.
hadronized Dec 24, 2016
cf74fd5
Fixed typo.
hadronized Dec 25, 2016
042b8e4
Strengthened the RFC with comments from people on the PR.
hadronized Feb 15, 2017
88d3074
Update 0000-trait-alias.md
durka Mar 6, 2017
5d0b4fe
Merge pull request #1 from durka/patch-9
hadronized Mar 6, 2017
819d8f9
fix object safety section
durka Mar 6, 2017
8a72471
just one lifetime
durka Mar 6, 2017
554c4c1
Merge pull request #2 from durka/patch-10
hadronized Mar 6, 2017
7b63d30
Added a teaching section and question about hidden free type variables.
hadronized Mar 7, 2017
6601146
Fixed teaching example – spotted by @eddyb.
hadronized Mar 7, 2017
b1be75b
Removed a question from the unresolved ones.
hadronized Mar 7, 2017
90ce5c3
Trait alias summary updated.
hadronized Mar 7, 2017
f04d4b2
Moved trait alias type vs. trait keyword in alt. section.
hadronized Mar 7, 2017
f269f9a
Added issue reference to trait alias RFC.
hadronized Mar 7, 2017
3fc5568
Fixed a typo in the teaching section of the trait-alias RFC.
hadronized Mar 7, 2017
8182509
Hygiene.
hadronized Mar 22, 2017
83322de
Refactoring a little bit and added an unresolved question about trait…
hadronized Mar 22, 2017
310c7fe
Proposal for pre-condition & implication bounds.
hadronized Mar 22, 2017
eb24a49
Typo.
hadronized Mar 22, 2017
4d99e23
Syntax for Trait<Item = AssociatedType>.
hadronized Mar 22, 2017
54ca931
Typo.
hadronized Mar 22, 2017
bf3414d
expanded detailed design text to include explicit examples of paramet…
pnkfelix Apr 13, 2017
80dbc13
Explicitly point out alternatives to `trait Alias = where PREDICATES;`
pnkfelix Apr 13, 2017
a2f8020
Add section pointing out how associated item ambiguity is handled.
pnkfelix Apr 13, 2017
dcec407
Spell out that it is an error to override an equivalence constraint.
pnkfelix Apr 13, 2017
b5ff949
Merge pull request #3 from pnkfelix/add-parametric-trait-alias-examples
hadronized Apr 13, 2017
2b14c14
Merge pull request #4 from pnkfelix/alternatives-to-equals-where
hadronized Apr 13, 2017
5c94f49
Merge pull request #5 from pnkfelix/mult-unbound-assoc-types-with-sam…
hadronized Apr 13, 2017
2a1a5b2
Merge pull request #6 from pnkfelix/associated-type-rebinding
hadronized Apr 16, 2017
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
79 changes: 79 additions & 0 deletions text/0000-trait-alias.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,79 @@
- Feature Name: Trait alias
- Start Date: 2016-08-31
- RFC PR:
- Rust Issue:

# Summary
[summary]: #summary

Traits can be aliased the same way types can be aliased with the `type` keyword.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this summary still accurate? I think it should be s/type keyword/trait keyword/, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The initial intention was to state that we can have alias the same way we already have with the type keyword and types. But you’re right, it’s confusing. I’m updating that.


# Motivation
[motivation]: #motivation

Sometimes, some traits are defined with parameters. For instance:

```rust
trait Foo<T> {
// ...
}
```

It’s not uncommon to do that in *generic* crates and implement them in *backend* crates, where the
`T` template parameter gets substituted with a *backend* type.

If someone wants to write `Foo` code and be compatible with all backends, then they will use the
*generic* crate’s `Foo<_>`. However, if someone wants to freeze the backend and keep using the same
one for the whole project but want to keep the ease of backend switching, a good practice is that
the backends should exporte a specific version of the trait so that it’s possible to use `Foo`
instead of the more explicit and unwanted `Foo<BackendType>`.

# Detailed design
[design]: #detailed-design

The idea is to add a new keyword or construct for enabling trait aliasing. One shouldn’t use the
`type` keyword as a trait is not a type and that could be very confusing.

The `trait TraitAlias = Trait` was adopted as the syntax for aliasing. It creates a new trait alias
`TraitAlias` that will resolve to `Trait`.

```rust
trait TraitAlias = Debug;
```

Optionnaly, if needed, one can provide a `where` clause to express *bounds*:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: typo. "Optionally"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Optionally :-)


```rust
trait TraitAlias = Debug where Self: Default;
```

Trait aliasing to combinations of traits is also provided with the standard `+` construct:

```rust
trait TraitAlias = Debug + Default; // same as the example above
```

Trait aliases can be used in any place arbitrary bounds would be syntactically legal. However, you
Copy link
Contributor

@withoutboats withoutboats Feb 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In terms of structure, the detailed design could probably be split into two sections - syntax and semantics. Everything above this paragraph would be syntax, whereas this paragraph should be expanded into the semantics secion.

There are basically two cases semantically that we're allowing (and a third we're not - defining impls). The first is bounds, which is sort of straightforward, but has some question still around which bounds get elaborated as Niko discusses here. That is, in trait Foo<T: Bar>: Baz<T>;, do we enforce that T: Bar? I'm not sure what the answer is, @nikomatsakis probably should comment.

The other case is objects. You don't mention it, but an alias needs to be object safe in order for it to be used as an object. I believe this is the requirements for an alias to be object safe:

  1. It contains zero or one object safe traits and zero or more of these other bounds: Send, Sync, 'static (that is, trait Show = Display + Debug would not be object safe).
  2. All the associated types of the trait need to be specified.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I’ll draft something soon about that. :)

cannot use them in `impl` place but can have them as *trait objects*, in *where-clauses* and *type
parameters declarations* of course.

# Drawbacks
[drawbacks]: #drawbacks

The syntax `trait TraitAlias as Trait` makes parsers need a lookhead (`=` or `as`?).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this should say = as well (or move the as syntax to Alternatives).


# Alternatives
[alternatives]: #alternatives

A keyword was planned, like `alias`:

```
alias Foo = gen::Foo<Bck0>;
```

However, it’s not a good idea as it might clash with already used `alias` in codebases.

# Unresolved questions
[unresolved]: #unresolved-questions

The syntax `trait TraitAlias as Trait` is not yet stabilized and needs to be discussed.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be changed to = as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo fixed, but shall we just remove that part?