What restrictions should be applied to aliases?

[zygoloid]

Summary of issue:

We currently have contradictory design documentation for aliases. The top-level design page says:

Note that the right-hand side of the equal sign (=) is a name not a value, so alias four = 4; is not allowed. This allows alias to work with entities like namespaces, which aren’t values in Carbon.

Whereas the specific documentation on aliases says:

Carbon provides a fully general name aliasing facility to declare a new name as an alias for a value; everything is a value in Carbon. This is a fully general facility because everything is a value in Carbon, including types.

... which would allow alias four = 4;.

Previously in leads issue #749, we had decided on the "aliases are only for names" rule; while we did not clearly define what a "name" is, we did say that Int(32) isn't one.

The toolchain implements a third rule, that the right-hand side of an alias must either be a type literal instruction or a name reference. This allows alias X = Int(32).PromotedType; but not alias X = Int(32);, and allows alias X = type; but not alias X = bool; (rewritten to Core.Bool()) nor alias X = i32; (rewritten to i32).

So, what rules do we want?

Details:

In various parts of our design, we are currently using alias syntax for the following:

• Aliasing a namespace
• Aliasing a package
• Aliasing a function
• Aliasing a method of an interface into a class
• Aliasing a type

Presumably we want the above to all work.

For C++ migration, it would also be good if we had a consistent story for how to migrate C++'s

using MyT = YourScope::YourT;

and

using YourScope::YourName;

into Carbon. Currently the story we have is that you use an alias if there are no template arguments involved, and otherwise presumably you would use a let template... declaration once that's supported. That does not seem like a good story.

Any other information that you want to share?

We once had an idea that it would be good if alias expansion could be done without any additional semantic information. I believe the intent was to support a really simple mapping from names to the named entity, in order to allow simple tools to accurately understand some portion of the Carbon semantics. In particular, at the time we thought we would allow aliases to be used when redeclaring entities, so that redeclarations of the same entity could differ in whether an alias was used. We have since decided against that; declarations of an entity must use the One True Name of the entity and all of its enclosing scopes. So the restriction to pure names may no longer be justified -- and indeed because aliases can be imported, I'm not sure the restriction ever really bought us anything.

[zygoloid]

My current preference is to broaden aliases to cover all the C++ using use cases. I want alias to be our tool for providing simple entity renaming / rescoping. For that reason, I think it makes sense to restrict it to simple entities that we want to be able to appear in scopes -- types, functions, and so on -- and not allow arbitrary constants to be aliased. But I think that's the only restriction we need. So I think we should use a rule such as:

If the right-hand side of an alias is not a namespace, package, function, interface member, or field, it is implicitly converted to type type. The possibly-converted result is category-converted to a value expression, and the result is required to be a constant. The alias names that constant.

(I'm not sure that that's a complete list of the types we want to allow, but generally-speaking I think we want to allow builtin types that are used as the types of introduced entities, and we want to disallow aliases for values of class types and other data types. I would be inclined to allow aliases for stateless functions but disallow aliases for lambdas with captures.)

One corner case that the above approach handles is: alias X = (i32, i32);, which I think should be an alias for the type (i32, i32) as type, not for the tuple value of type (type, type).

[geoffromer]

Note that #5389 currently proposes that alias A = B is equivalent to let A:? auto = B, with the restriction that B mostly can't be a runtime expression. That's more than enough expressive power to handle all C++ using use cases, but it allows aliasing arbitrary constants, and it means that e.g. alias X = (i32, i32) defines X as a tuple, not a type.