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.)
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?
Why not use the use OldName as NewName syntax for renaming types? This is already used to “rename” modules.
Continuing the discussion from Rename 'type' to 'alias' before 1.0!:
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;
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.
How would using
use TypeA as TypeB
work if you wanted something like
type MyType = Box<TraitA + TraitB + TraitC>
?
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.
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;type is also used for associated types, so it still has to be a keyword even if it wasn’t used for type aliasing.
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);
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.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.