Alias syntax

[jonmeow]

In general I think there's consensus that we should have aliasing functionality. A skeletal framework is noted at:
https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/aliases.md

I believe there's consensus on the alias keyword, and the overall alias <resulting identifier> <symbol/keyword> <identifier being aliased>. Putting the resulting identifier first is consistent with var and fn.

There will probably be multiple uses of alias that are possible: the two I can think of right now are (1) to generally alias one name to another, such as alias MyInt = i32; or alias MyFn = OtherFn; and (2) to alias a name to a particular binding of a template or generic, such as alias i32 = Int(32). In neither case is a new function/type/whatever defined: a significant purpose of alias is to assist code refactoring, and so aliases will generally be transparent to code. I believe there's agreement on these particular use-cases, but please let me know if not.

Where I believe there's disagreement is on the symbol/keyword that should be used. We discussed a few options yesterday; to list here to help leads think about options (I can include add some arguments for/against each if desired):

• alias A = B
• alias A for B
• alias A <- B
• alias A: B
• alias A := B
• alias A ~ B
• alias A to B
• alias A is B

For prioritization of this question, I think the alias i32 = Int(32) example demonstrates where I see the utility of alias. It would be nice to define prelude includes in terms of alias, and that's why I'd like to see if we can establish the syntax. However, it's not blocking anything right now.

[chandlerc]

I'm not at all confident in allowing the alias name = Int(32) case... I think that is a different problem.

I had suggested that the semantics of alias should be 100% in the domain of names, not in any other domain. Which means that both A and B should be names and not expressions.

[josh11b]

In discussions, @chandlerc and @zygoloid have put forth that alias would only be used for names, not case (2). Case (2) would be handled by let.

[jonmeow]

Okay, let's ignore Int(32) for now, and focus on the basic syntax.

[chandlerc]

Of the syntaxes here, I like to and for. But neither are perfect.

All of the others have (or may have in the future) very similar but importantly different semantics in the value/expression domain, and so using them here seems less desirable. If they had exactly the same semantics, it might be really nice, but the difference seem inescapable and important.

to has some downsides. You have to rely on alias A ... indicating that A is the newly introduced name here, or rely on that pattern with other introducers. to itself doesn't provide any unambiguous directionality, or worse I think it'll suggest a directionality opposite the intent.

for I think has good directionality. The only downside I see is that it is used elsewhere in the language for a completely different purpose. On one hand, it isn't likely to cause confusion. On the other hand, it is a touch unfortunate to reuse in this way.

I think I end up leaning towards for here. Curious what others thing or if they have other suggestions.

[jonmeow]

@chandlerc Can you please elaborate on what issues you see with =? I think there may be support for it, so I think it's important to understand your concerns.

I think I should add, = being used in var and parameter contexts, I view alias semantics as similar in that it's assigning a value (the alias target) to the alias identifier. After assignment, the two identifiers are "equal".

[jonmeow]

Capturing a bit of discussion today here, @KateGregory brought up that for can have confusing directionality, such as substitute honey for sugar in cooking being taken in the opposite direction (removing honey, adding sugar) by a non-trivial number of people. A stackexchange discussion I found suggests this is because most similar phrasings, such as substitute honey with sugar, have the opposite directionality.

[chandlerc]

The concerns with = are primarily that it seems a bit out of place -- this isn't really assignment or initialization.

Leads also discussed is but it both seems to have some directional ambiguity and also seems likely to be interpreted more as <expression> is <type>, somewhat similar to how as is likely to be read.

There was also discussion of a syntax that puts alias in the middle like let x alias y;, but there were concerns about overloading the let introducer with a very different concept.

At the end of the day, the leads have consolidated on alias x = y; as the "least bad" option on the table, so lets move forward with that for now.

• It has an extremely strong and unambiguous assumed direction for programmers.
• It Will be correctly understood by readers unfamiliar with Carbon.
• It is reasonably terse.

If we come up with better syntax (or a better model), we can try to revisit this, but for now, let's make progress with this option.

[jonmeow]

Filed #2000 to track this.