[SUGGESTION] Add support for defining type aliases.

[leejy12]

Recently cppfront added the ability to define user-defined types. I want to extend this feature to be able to declare type aliases. My proposed syntax looks like this:

DWORD: type = u32;

// templated type aliases
MyPair: <T> type = std::pair<T, T>;

// nested aliases work too
MyVector: <T> type = {
    size_type: type = std::size_t;
}

This will be compiled to (skipping boilerplate):

using DWORD = cpp2::u32;

template<typename T> using MyPair = std::pair<T,T>;

template  <typename T> class MyVector {
    public: using size_type = std::size_t;
};

Will your feature suggestion eliminate X% of security vulnerabilities of a given kind in current C++ code?
No.

Will your feature suggestion automate or eliminate X% of current C++ guidance literature?
Yes, this syntax uses the l-to-r declaration syntax already used widely in Cpp2, so there's no need to teach the syntax
using alias_name = type_name.

I have already implemented this feature locally so I can provide a PR.

[filipsajdak]

I am currently missing that feature on the cpp2 side.

I like the syntax.

[AbhinavK00]

Nice feature, but one thing I'd like to point out, it's important to have distinction between actual user defined types and type aliases. The syntax could be same but we can have a different keyword instead of type.
One example could be typealias, so the given examples would be

DWORD: typealias = u32;

// templated type aliases
MyPair: <T> typealias = std::pair<T, T>;

// nested aliases work too
MyVector: <T> typealias = {
    size_type: typealias = std::size_t;
}

Any keyword that fits can be chosen but it's the distinction which I emphasize that should be present.

[leejy12]

@AbhinavK00 You make a very good point and I've actually thought about this while implementing.

Currently in my implementation, if initializer.statement is a statement_node::compound, cppfront prints a new class. If it's a statement_node::expression (no braces) then cppfront prints using ..., but I felt this approach was very hacky.

If the distinction between UDTs and type aliases is significant enough to warrant an introduction of a new keyword, I could try implementing it that way as well.

[msadeqhe]

Nice feature, but one thing I'd like to point out, it's important to have distinction between actual user defined types and type aliases. The syntax could be same but we can have a different keyword instead of type. One example could be typealias, so the given examples would be

DWORD: typealias = u32;

// templated type aliases
MyPair: <T> typealias = std::pair<T, T>;

// nested aliases work too
MyVector: <T> typealias = {
    size_type: typealias = std::size_t;
}

Any keyword that fits can be chosen but it's the distinction which I emphasize that should be present.

I've read in a comment from @hsutter that he wants to use is keyword for class inheritance, maybe is can be a good candidate for type aliases too, because a type alias is exactly the same as the other type without any additional definition. I don't know the syntax of class inheritance yet, but maybe it would be something like this:

DWORD: type is u32;

Edit: Also is keyword doesn't make a good distinction between user defined types and type aliases. I withdraw it! In this case, = seems more natural than is keyword.

[hsutter]

Good suggestion. I do intend to implement aliases down the road, and I haven't settled on a syntax for them yet.

One issue with DWORD: type = u32; is that, while it's not legal today and therefore is available, it could close a door to future development because it's a syntax we might naturally use for strong typedefs (the syntax implies "declare a new separate thing initialized from this existing thing," like with x: int = 42; where x is not an alias for 42, it's a copy).

I am considering using is declaratively in a couple of places, such as to declare base classes (coming soon). Here's the key test I'm using to decide whether to use is declaratively: If you declare something with is, then it should be guaranteed to later evaluate true if you ask the equivalent is test, and that is test should be supported. In this case, if DWORD is an alias for u32, then if we make DWORD is u32 be true (not currently supported, but reasonable), then a syntax that includes is would be a candidate for declaring the alias.

[jcanizales]

Nice feature, but one thing I'd like to point out, it's important to have distinction between actual user defined types and type aliases. The syntax could be same but we can have a different keyword instead of type.

What's your motivation for this, @AbhinavK00?

[AbhinavK00]

No real motivation I guess but there should be a distinction between strong typedefs and just aliases to typenames.
Consider the two syntaxes considered above,

DWORD : typealias = i32;

This is just another name and DWORD can be used anywhere in place of u32, this doesn't have many use cases.
Then there's this,

DWORD : type is i32;

This is like wrapping an i32 in a struct, it's different from i32, can be casted to an i32 and need to be casted explicitly if using it in place of an i32 and vice-versa.

So no real motivation, but I just put it out in case if others agree.

[JohelEGP]

One issue with DWORD: type = u32; is that, while it's not legal today and therefore is available, it could close a door to future development because it's a syntax we might naturally use for strong typedefs (the syntax implies "declare a new separate thing initialized from this existing thing," like with x: int = 42; where x is not an alias for 42, it's a copy).

But what is a "strong typedef"? It'd be great if, down the road of development of Cpp2, we could find the answer meant for Cpp2. Although, with metaclasses, we might be able to author better answers than today's Cpp1.

[jcanizales]

As a library author, when you export a type name sometimes it refers to a class you defined, and sometimes you want it to be just an alias to something else, without leaking that detail to the user of the library.

In current C++ the leakage is unavoidable, for example because the user can forward-declare your classes, but not an alias. Hopefully in Cpp2 this specific case is not an issue because forward-declaring is made unnecessary. But the general request remains, of letting a library author export an alias that is indistinguishable from a type's "true" name.

But what is a "strong typedef"?

I'm guessing Herb is thinking of compile-time modification of types, for which whether you're modifying the original or a copy makes a difference?

[hsutter]

On thinking about this further, two things:

1. I want to handle aliases in general, not just type aliases -- also namespace, function, and object aliases. For example, namespace aliases already exist in Cpp1 and are useful. I don't want to lose that convenience, I just want to make it more regular with the rest of the language.

2. I want a consistent general syntax that works for all of these. So for example the word typealias is tempting, but that word would work well only for types, and then we'd be getting pressure to add namespacealias etc. too.

3. That syntax should be a declaration syntax, since we are declaring a new name -- it just happens to be an alias rather than a standalone entity. So the syntax should start with name :, but should somehow be different from the name : type = value Cpp2 uses for all declarations to express that this is an alias, not a standalone entity.

So after some thought of brainstorming options, include ones that include is, the one I like the best is to use exactly the declaration syntax, but with == to connote equality with an existing entity, instead of = which connotes setting the new entity's value. For example:

lit: namespace == ::std::literals;

pmr_vec: <T> type
    == std::vector<T, std::pmr::polymorphic_allocator<T>>;

func :== some_original::inconvenient::function_name;

vec :== my_vector;  // note: const&, aliases are never mutable

Checking it in now...

[AbhinavK00]

Question: What does the following line mean?

smth :== something::smth;   

And the point about const& too, didn't get those.

Also, these are same as using counterparts to cpp, yes?

Edit: Nevermind, got it

[msadeqhe]

Thanks. Nice reasonable syntax.

I think x :== y; is a short form for both x: function == y; and x: variable == y;, because function and variable aliases are distinguishable from y.

Maybe also z in x: z == y; could be optional for both namespaces and types.