Improved syntax for defining new variables

[DartBot]

This issue was originally filed by girishrv...@gmail.com

---

Code like

  Map<int, View> views = new Map<int, View>();

is redundant and require a lot of typing especially when the class names are long. Since people hands are very soft it would be great if this could be shortened as

  views := new Map<int, View>();

Yes. this is just for convenience. But convenience has been a great force in history.

The proposal is only for assignments whose right hand side is a new keyword.

[DartBot]

This comment was originally written by is...@google.com

---

I would look for the type information on the left side of a variable, and this construct is definitely against the conventions of Java / C world...

Btw. you can use the following compact code instead:
 
  Map<int, View> views= {};

[DartBot]

This comment was originally written by @seaneagan

---

Map<int, View> views= {};

I think that should yield a type warning, since it's taken to be the same as:

Map<int, View> views= <String, Dynamic>{};

However, type inference allows you to do:

var views = new Map<int, View>();

[DartBot]

This comment was originally written by giri...@gmail.com

---

@#­1
For maps may be that is a short code. But that doesnt work for an arbitrary object. For eg:

  view := new View();

@#­2
Sorry. I didnt understand your comment. Are you saying that Dart has type inferencing?

But your suggestion seems to solve the problem. Except that after i type

  var views = new Map<int, View>();

i should get code completion after views. in the dart editor. I guess this is not difficult to implement.

[DartBot]

This comment was originally written by @seaneagan

---

Yes, Dart supports type inference by making types optional, and leaving it up to the tools to implement. I believe they have implemented local variable type inference in the analysis engine used by dart editor, but if not, then certainly at some point they will.

[madsager]

Added Area-Language, Triaged labels.

[gbracha]

There is often a degree of redundancy between type annotations on variables and the expressions being assigned to them. To a degree, this is deliberate - that redundancy indicates programmer intent and provides the typechecker with more information so it can detect inconsistencies.

That said, there is always the desire to reduce/eliminate redundancy. One mechanism for this is type inference. Our view is that inference is best supported via tooling rather in the language. This is especially critical in an optionally typed language. For example:

var m = new Map<int, String>();

Has a meaning that is significantly different from

Map<int, String> m = new Map<int, String>;

So we cannot have the language do inference here. Instead, a tool can put in the declaration for you.
Other ways to reduce the inconvenience might be typedefs that make the annotations shorter. More radical ideas are possible as well. We might say introduce typed variables via a different keyword

def m = new Map<int, String>();

and say that in this case, the type of the expression is the type of the variable. But this comes with costs as well - new keywords, two ways of doing things etc. So I don't really like it. I think tooling is the way to go.

---

Removed Type-Defect label.
Added Type-Enhancement, Accepted labels.

[gbracha]

Set owner to @gbracha.

[gbracha]

Tooling should support this, not the language.

---

Added WontFix label.