Rename 'type' to 'alias' before 1.0!

[phildawes]

Hello!

I think we should rename ‘type’ to ‘alias’ before 1.0.

• type doesn’t create a type
• it sounds and looks similar to ‘typedef’ in C/C++, but an expectation of type safety can cause bugs.

e.g.

type Price = i32;
type Quantity = i32;

fn create_order(name: &str, qty: Quantity, px: Price) {
   // ...
}

fn main() {    
   let px: Price = 30000;
   let qty: Quantity = 6;
   create_order("thing", px, qty);   // BUG!!!
}

Even ‘rust by example’ calls the section describing ‘type’ ‘alias’! http://rustbyexample.com/type/alias.html

Cheers,

Phil

[sanxiyn]

While I am partial to the idea, doesn’t C/C++ typedef work exactly the same?

[nodakai]

+1

Perhaps it was imported from Ocaml in which type can create both of a type alias and a distinct new type.

[barosl]

This had also confused me.

[ubsan]

Please this. type makes very little sense as creating an alias for a type, while alias is very clear.

@sanxiyn Yes, but this isn’t typedef, it’s type, which, at least in my opinion, is much less clear. I wouldn’t mind typedef, but I’d prefer alias.

[burgos]

D language also have distinct typedef and alias, where typedef created a completely new type, while alias was just generating a new name for the existing:

typedef int NewType;
alias int NewName;

int x = 5;
NewType t1 = cast(NewType) x; // Explicit casting required
NewName t2 = x;

However, typedef is now deprecated due the inflexibility and delegated to the library. See bugzilla entry on this: https://issues.dlang.org/show_bug.cgi?id=5467

+1 for the proposal.

[jostmon]

+1 for sure. This had me confused as a newcomer

[blaenk]

I’m not against this, but I don’t think it’s all that confusing.

Given:

type Quantity = i32;

It can be read as "type Quantity is i32", there isn’t much there that implies that it’s creating a new type altogether.

[naicode]

+1 alias would be much clearer and type (and similar names) would be free for future use if needed (e.g. if a new type creating alias is added or similar).

[troplin]

If this was C++ I would agree:

type Quantity = i32;

this would creates a new variable of type “type” and assigns i32 to it. It’s perfectly reasonable that this creates an alias, not a new type, like:

int value = 32;

this does not create an entirely new integer value that didn’t exist before but it’s just an alias. You can use value and 32 interchangeably. (Of course you cannot create entirely new int values at all)

But rust ist not C++, so the correct syntax for aliases (type variables) should be:

let Quantity: type = i32;

[kainino]

I do support this. However, to bring it a little bit of history from Haskell:

• type does almost exactly what it does currently in Rust: it creates a (mostly) interchangeable alias.
• newtype is a single-constructor data (an ADT, algebraic data type). It gets its own constructors, typeclasses, function signatures, etc. It’s much like saying:

struct Foo { /*...*/ };
struct Bar { pub f: Foo }
impl Bar {
    fn new(f: Foo) -> Bar { Bar { f: f } }
    /*...*/
}

(I think. My Haskell is a bit rusty. No pun intended.)

[liigo]

+1 alias is much clear in semantic, while type is a bit ambiguous. please do it before 1.0.

[tomjakubowski]

If it’s possible I would rather extend use to allow this, like C++'s using keyword. Type -> alias feels like a net 0 to me.

[bjadamson]

Please do this before 1.0. +1

[iopq]

I’ve seen a few questions on Reddit why their new types don’t work as expected. I think this is confusing to newcomers, and I would support this change.

[petrochenkov]

Will Rust ever support aliases for traits, or for lifetimes, or for something else (expressions?!)? What syntax will they have?

trait MyTrait = Trait; // Similar to the current syntax
alias MyTrait = Trait; // Similar to the proposed syntax
use Trait as MyTrait; // Syntax of module aliases reused
/*...*/; // Something completely different

And how will this thing

trait Tr {
  alias Ty = int
}

be called - associated alias? : )

I’m trying to put this proposal into wider context.

[Nemikolh]

If we consider associated items, it seems more appropriate to keep using the type keyword. Consider writing this:

trait Graph {
    alias Node;
    alias Edge;
}

Against this:

trait Graph {
    type Node;
    type Edge;
}

The type keyword seems more appropriate as you want a library user writing a type that verify the trait Graph to provides the types Node and Edge.

For general alias case: +1 for the proposal

[pcwalton]

type in Rust works exactly as I expect it to work, based on functional programming experience. Note that, as @Nemikolh pointed out, alias is confusing in associated type context.

[iopq]

Could those uses still have type while cases where it’s more of an alias to be alias? I’m just thinking out loud, associated items seem like they have a slightly different use of type.

Shouldn’t there be a difference between type and newtype?

[blaenk]

We already have newtypes in Rust.