Chandler CarruthandRichard Smith
94d2c1c6d4
We've talked about adding the title to the filename several times over the years and it seems really valuable. This requires us to compute a "slug" for the title spelling that can be part of the filename. Beyond that, we crossed 7000 recently, and so it seems likely that we will need to add digits sooner rather than later here, so this goes ahead and moves us to 6 digits so we don't have to adjust again for a reasonable length of time. To implement this and ensure we can sustain it going forward this adds a tool to our pre-commit that validates (and corrects if needed) the filename. In order to update everything and keep links working, there are a _lot_ of changes, but the most interesting for direct review are in `proposals/scripts`. Assisted-by: Antigravity with Gemini --------- Co-authored-by: Richard Smith <richard@metafoo.co.uk>
6.1 KiB
var ordering
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: variableand thenType variablesyntax 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
ininstead 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
varand:. - 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:
- Matches Swift, Rust, Kotlin, Python3, and many smaller languages (Ada, Pascal languages like Delphi and Modula-3, Eiffel, Nim, Pony, Zig).
- Names will line up better with method names in a
structdefinition.
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.