Document the reasons of putting types before variables

[Leedehai]

This is more of an idea of improvement in documentation rather than an error report.

Hi, Dart adopted a syntax where a variable type is put before the variable name, like C and Java:

const int a = 0;

Given that

• the newer-ish languages like TypeScript, Python (with type hints), Swift, Kotlin, Rust, and Google's very own Go all elected to put types after variable names (and consequently have a dedicated keyword to declare functions). People wrote a lot to justify this type-last syntax, like
  • simpler parser,
  • similarity to English syntax,
  • better readability (like Go's arguments about pointers, which don't completely apply to Dart of course),
  • optional type declaration due to type inference, etc.
• users working on mobile apps tend to be used to Swift and Kotlin, and they form the main target user base of Flutter (especially before desktop support),

It feels there's a specific technical reason for Dart to make this choice, not just taste or frugality to save a few characters. For educational purposes, could you document why it is so? (like this question and answer, which is mentioned in the official doc)

Thanks.

[lrhn]

The answer is very simple: The goal of Dart 1 was to be familiar and unsurprising to people coming from JavaScript, Java and C#.
Therefore it used a syntax which was similar to those languages, which all derive from the C syntax.

[Wdestroier]

void RtlInitUnicodeString(UnicodeString string, Pointer<WideString>? sourceString) {}

is 3 characters shorter than

RtlInitUnicodeString(string: UnicodeString, sourceString: Pointer<WideString>?): void {}

That's a win for me.

[Levi-Lesches]

Another thing: it's easier to parse in some cases:

age: int = 42
model: MyClass = MyClass()

int age = 42;
MyClass model = MyClass();

Instead of reading "this is a variable age of type int", it's more natural to say "here is an integer that represents age". model is a little more subjective: the name model is a good start, but so is knowing that it's an instance of MyClass. Personally, I've gotten used to the "here is an X that represents Y" semantics, and they are pretty familiar when jumping from language to language.

[lrhn]

@Levi-Lesches

Don't understimate the effect of habit. You are used to seeing int age, pattern-match the int instantaneously, and have your eyes skip to the name, which is really the most important part.

Someone more used to the other syntax will see age: and think "someone is defining a variable named age". Then comes the type, which they skip over, and go directly to the =, if they don't need to know it right now (or can guess that an age is going to be an int anyway).

You can get used to either, and for short and simple examples it probably won't matter anyway.

Now take:

class Person:
  name: String;
  address: AddressStruct;
  occupations: Map<Interval<DateTime>, OccupationRecord>;
  dateOfBirth: DateTime
  
  // ...

and compare it to:

class Person {
  String name;
  AddressStruct address;
  Map<Interval<DateTime>, OccupationRecord> occupations;
  DateTime dateOfBirth;

  // ...

and tell me which one is quicker to scan and get an idea of the properties of.

[cedvdb]

Out of curiosity : changing something like this is outside the realm of possibilities ? A massive python 3 type of turn, making all documentations and articles essentially outdated. It doesn't seem like good trade-offs but I'm curious since you must have considered it at some point for a bunch of feature.

[lrhn]

I think it's very very unlikely that Dart will change its syntax completely at this point.
If anything, I'd put it as more likely to support two alternate and equally valid syntaxes at the same time, than to invalidate all existing code. Even that is ... not really within reason. It'd just require everybody to learn both syntaxes, and then we have twice the learning curve.

We have considered "types on the right" several times, but it's never really been a viable change.

[cedvdb]

Iff it is agreed upon that types after names is a better alternative then there is also the possibility to have 2 valid syntax + a lint to prefer types after names and a dart fix addition. The dart community is pretty swift to change.

It doesn't seem universally agreed upon though (for now) judging by the comments here