Rename 'type' to 'alias' 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.

[kainino]

I stand enlightened. I hadn’t ever tried… I would be a fan of having the names alias and newtype. Though alias isn’t that descriptive either, maybe type is just fine.

(EDIT: iopq’s suggestion to have both seems good, but I haven’t yet touched associated types, either.)

[naicode]

Like @Nemikolh pointed out alias looks quite bad in context of associated items maybe there is a name witch clearly says that it is not a new type without making associated types look bad

What do you think about typename witch clearly points out that it’s just a additional type name and nothing more?

[theme]

Why not use the use OldName as NewName syntax for renaming types? This is already used to “rename” modules.

[bombless]

Continuing the discussion from Rename ‘type’ to ‘alias’ before 1.0!:

Why not use the use OldName as NewName syntax for renaming types? This is already used to “rename” modules.

Or just use use A = B Several hours ago I tried to write:

enum E{ A(()), B }
use make_a = E::A;

for now we can only write it this way:

enum E{ A(()), B }
static make_a :fn(())->E = E::A;

[gulbanana]

the specific choice of name for this keyword really doesn’t matter. there’s precedent for the current version but however it’s spelled it has the same meaning. people will learn either way.

pursuing apparent syntactic consistency at the cost of overloading semantics, such that “use” meant multiple different things in different contexts, would be counterproductive.

[daboross]

How would using

use TypeA as TypeB

work if you wanted something like

type MyType = Box<TraitA + TraitB + TraitC>

?

[theme]

The logical way to do it would be:

use Box< TraitA + TraitB + TraitC > as Mytype;

Which looks a bit weird. I didn’t think about this case when proposing that syntax.

[bombless]

Very cool idea. And removing type form keyword list is really sweat, too.

type MyType = Box<TraitA + TraitB + TraitC>

would become

use Box<TraitA + TraitB + TraitC> as MyType;

[AndyShiue]

type is also used for associated types, so it still has to be a keyword even if it wasn’t used for type aliasing.

[sellibitze]

doesn’t C/C++ typedef work exactly the same?

It does. Although, a fraction of the C++ community does not like typedef either. Since C++11 they now can write

using fun_ptr = void(*)(int);

[bombless]

I was thinking about a new type definition syntax: turn

struct Foo;
struct Bar<T> { value: T }

into

type Foo: ();
type<T> Bar: struct { value: T };

. It’s just like bounds,

fn foo<T: Trait>() {}

means T is not as type Trait but fits the limitation of Trait. So we don’t change much to unify the enum/struct definition syntax, and we find a new way to distinguish alias type and defining new type.

Current struct/enum definition syntax can remain as syntax sugar.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.