Skip to content

Latest commit

 

History

History
166 lines (121 loc) · 6.15 KB

p0618.md

File metadata and controls

166 lines (121 loc) · 6.15 KB
Raw

var ordering

Pull request

Table of contents

Problem

As stated by on Re-evaluate core variable & parameter identifier/type order (including a default for parameters) #542:

Somewhat condensed, bullet-point-y background for this question:

  • We've been using first Type: variable and then Type variable syntax in variables, parameters, and other declarations.
  • This was primarily based on a lack of compelling data to select a better syntax, with trying to stay similar to C++ as a fallback.
  • It was specifically intended to be revisited. The expected trigger for this was some form of broader user data (surveys at least of decent #s of developers, or potentially real user studies).
  • However, we have gained specific new information as we've filled out a great deal of the surrounding syntax. We have also gotten some data on parsing challenges (although perhaps surmountable challenges) of Type variable.
  • We also don't have a short/definite timeline to start getting useful data.
  • The leads should re-evaluate the core variable syntax based on the new information we have, but without trying to wait for data.
    • We can always re-evaluate again if and when data arrives and indicates any need for it.
  • The leads should do this ASAP and make a decision so that we can focus our energy, reduce frustrating discussions, and have consistent syntax in examples and proposals.

Background

Background may be found in the related #542 and Docs.

Proposal

Two changes:

  • Switch to <name>: <type>, replacing <type>: <name>.
  • Use in instead of : in range-based for loops.

Note these changes were largely implemented by #563.

Rationale based on Carbon's goals

Both of these changes are done for consistency with other modern languages, particularly Swift and Rust. The switch from : to in is for ease of understanding and parsing.

Alternatives considered

Type ordering

Alternatives are pulled from Docs.

<type>: <name>

var String: message = "Hello world";

Advantages:

  • Roughly matches the order of C, C++, C#, D and Java, except with extra var and :.
  • Type at the beginning puts most important information up front.
  • Name followed by default matches assignment statements.

Disadvantages:

  • Existing languages that use a : put the name before and the type after (universally).
  • Beyond simple inconsistency, the overlap of : in this syntax with different order will add confusion for people working/familiar with multiple languages.
  • Does not end up having a syntax that is consistent with using colons for marking labelled parameters and arguments, such as how Swift does.
    • We currently do not plan to use a colon syntax for labelled parameters and arguments, regardless of the decision here.

Opinions vary:

  • Not friendly to optionally dropping the type: to represent auto type deduction.

<type> <name>

var String message = "Hello world";

Advantages

  • Matches C, C++, C#, D and Java the closest.

Disadvantages:

  • Creates parse ambiguity, particularly when we start adding syntax to the name to indicate that a parameter is labeled, etc.

Currently hard to see how we can make this work, since it isn't compatible with other choices, detailed in Docs.

<name>: <type>

var message: String = "Hello world";

Advantages:

Disadvantages:

  • Name separated from initializer; default doesn't match assignment statements.
  • Further from the simplistic appearance of common C and C++ variable declarations.

Opinions vary:

  • Existing languages typically make the ": type" part optional when an "= value" clause is present.

: versus in

The : operator for range-based for loops becomes harder to read, and more likely to cause ambiguity, when : is also used for var. That is, for (var i: Int : list) is just harder to understand than for (var i: Int in list). in is a favorable choice for its use in other languages.