Re-evaluate core variable & parameter identifier/type order (including a default for parameters)

[chandlerc]

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.

@josh11b has provided a really nice and pretty comprehensive overview of the choices here, as well as all of the ways the might interact with the more complete syntax picture here ranging from functions to match cases:
https://docs.google.com/document/d/1EhZA3AlY9TaCMho9jz2ynFxK-6eS6BwMAkE5jNYQzEA/edit?resourcekey=0-QXEoh-b4_sQG2u636gIa1A

[Update: the above link replaced https://docs.google.com/document/d/1iuytei37LPg_tEd6xe-O6P_bpN7TIbEjNtFMLYW2Nno]

The three core options outlined in that document are:

• "T:ND" or type-colon-name-default: Type: name = default.
• "TND" or type-name-default: Type name = default.
• "N:TD" or name-colon-type-default: name : Type = default.

If folks have other syntaxes they'd like to consider, I'd somewhat suggest building something similar to this document to allow folks to evaluate them. I would also suggest that we should focus our time here on picking an option based on the information we have and not expanding our options. I think this is something that we can (and likely will) revisit if we get new information in the future (including new, compelling syntaxes that have be tried out and clearly shown to be interesting to consider). Right now, I think the most valuable thing is to pick something and focus our efforts.

Relatedly, I'd like to avoid diving into long and detailed discussions of data (surveys, user studies, etc) that we should collect to inform this decision. I'm actually really interested in this area, and I think it is something the project should eventually do, but my goal with this question is to ask the leads to pick a syntax to use in the absence of effective / compelling data-based studies. I hope that makes sense to folks.

One bit of data that I think we can easily and immediately collect is just fresh polls of the existing community members. I'm going to create a comment on this issue for each of the three options above. Please react with a "thumbs-up" for all the options that you'd be OK with -- and I encourage being a bit generous here. Even if you'd rather not, unless it seems like a serious problem, I'd suggest giving it a thumbs-up. Please react to at most one of these options with a "rocket" to indicate your favorite. Putting this here so we have a bit more of a record and so folks not active on Discord can find it.

[chandlerc]

Thumbs-up for OK with T:ND, rocket if it's your favorite.

[chandlerc]

Thumbs-up for OK with TND, rocket if it's your favorite.

[chandlerc]

Thumbs-up for OK with N:TD, rocket if it's your favorite.

[KateGregory]

Decision: consensus is here for N:TD

[chandlerc]

A nit-picky question here, but useful for consistency: what formatting should we use?

I think the overwhelming answer is name: Type from surveying language examples, so I assume we should follow it.

FWIW, I had somehow seen name : Type used at some point in the past... But the only modern examples I'm finding w/ this formatting are Ada, F#, and some related but much more obscure examples. So I mostly wanted to confirm and document the canonical answer, I'm not expecting this to be interestingly contentious.

[KateGregory]

I would like to see our examples without a space before the colon and with one after, so name: Type. (Ideally any number of spaces including zero both before and after would work; nevertheless our samples, examples, and tutorials would adopt a style .of name: Type

[fowles]

Users will definitely want to be able to align things:

var foo    : Int = 1;
var barbaz : Int = 2;

and I do not think we should fight them on it

[chandlerc]

Users will definitely want to be able to align things:

var foo    : Int = 1;
var barbaz : Int = 2;

and I do not think we should fight them on it

Yep, I think we're all aligned that this is just about what the canonical formatting in examples looks like.

I'm even open to evaluating a more column-oriented formatting when/if we have a formatter tool, I just wanted to know what baseline to use in examples prior to that.

[chandlerc]

Closing this out as I think the majority of updates to our existing syntax examples have landed.