Many Flutter developers will be coming from languages like JavaScript.
In JavaScript, var means the same as dynamic in Dart.
In Dart 1.0, var also means dynamic.
However, in Dart 2.0, var means auto, as in, take the type of the expression on the right hand side.
This means that code such as the following fails:
var widget = new Row(...);
...
widget = new Container(...);
We should either make var mean dynamic or make var get the type that is the common denominator of all the expressions that are assigned to the variable. Otherwise we are going to be putting up a barrier to entry for a large class of Flutter developers who do not care about types at all.
JS doesn’t have a type system at all, so I don’t think you can claim that variable declarations “mean” any specific type. In, JS
123also means “123 as dynamic“. 🙂In C#, TypeScript, Swift, Scala, Go, Kotlin, Flow, Nim, Haxe, and Vala among others,
varmeans “infer the type from the initializer”. In languages with type systems, the clear precedence is that the wordvarimplies inference.We could swim upstream against that, but we’d be throwing away a ton of familiarity to do it.
Note that before strong mode,
varused to meandynamicin Dart too, and we changed it in part because many users over many years kept telling us how surprised they were by that fact. It clearly went counter to their expectations. (Unsurprising given how many of them are coming from languages wherevarmeans “infer”.)Making
varmeandynamicin strong mode would be a massive, massive breaking change, and it is, frankly, one that I see having negative value to most of our existing users. Doing inference forvarrevealed quite a few latent bugs in code that we converted to strong mode, and is a key enabler for type inference in the language in general.I do think that having a short three letter syntax for an un-inferred variable binding would be great, and would enable the users that you are concerned about to just write their code using a
dynamiccoding style and never have to worry about it. My preference would be to useanyfor this:Interesting. I’m surprised, actually. I would have expected Flutter would attract a lot of Java and Objective C programmers, and that those users would be comfortable with types.
Either way, I’m 100%% certain TypeScript and Flow have both attracted JavaScript developers including accepting their existing JS code and both of those languages define
varto mean “infer the type”.Better inference would be interesting, but a cheap and quick solution would be to just keep
varas meaningdynamicas it has so far, and introduce a new keyword (likeauto) for the inference version.https://www.google.com/trends/explore?date=2011-01-01%%202016-12-31&q=%%2Fm%%2F0h52xr1,%%2Fm%%2F010sd4y3,%%2Fm%%2F0n50hxv,JavaScript
On Fri, Oct 14, 2016 at 11:59 AM Cat-sushi notifications@github.com wrote:
Personally i would love to see
varto infer type of an expression instead being an alias fordynamic.That was one of the confusing moments when i discovered they are semantically the same in Dart 1.
Even though i’m faimiliar with JS
varsemantics, I was expecting it to infer type as it does in statically typed languages since 1. we havedynamicand 2. Dart often referred to be highly inspired by statically-typed languages which do just that.As of JS programmers who will get the error as in flutter/flutter#5968 i think after the first time they will adapt and won’t be alienated by such a tiny thing (same way as I wasn’t alienated when discovered
var==dynamic, though didn’t like that).Also, i would expect JS programmers to move to React Native rather than Flutter simply because it won’t force them to learn simillar yet different new language. And as soon as they did choose Flutter and have to learn Dart anyway, they also can learn the Dart’s semantics of
var.I don’t understand the argument that Flutter would mostly be adopted by javascript devs. I’d actually think the exact opposite. I don’t think that Flutter would be the tool that convinces a javascript devs to jump into the mobile space. Rather, I’d think existing mobile devs like myself who have felt the pain of re-creating the same project on multiple platforms, all with separate teams and bugs are who would find flutter appealing. I’d think the majority of flutter users would be coming from Java, Obj C, and Swift.