"var" as explicit non-final marker

[DartBot]

This issue was originally filed by [email protected]

---

Original discussed at https://groups.google.com/a/dartlang.org/group/misc/browse_thread/thread/c0975d735bb47eb6

Proposal:

Allow "var" before any type declaration as an explicit statement that the developer intends the variable to be non-final. The presence of "var" before a type has no effect on the program's behavior because it only declares what is already the default. The "var" is only there to document developer intent and for future static analysis tools.

If I've read the spec correctly, I intend section 5 to have the following, modified definition:

  finalVarOrType:
    final type? |
    var type? |
    type
  ;

Motivation:

Some developers prefer to work with single-assignment variables, but manually marking each variable as final is a burden. Making all variables final by default burdens other developers (see earlier discussions[1][2]). Without changes to Dart, "final-ists" could write a static analysis tool to warn about multiple-assignment:

  int x = 7;
  int y = 1;
  x = x + y; // tool warns: multiple assignment to variable "x"

Without this proposal, the tool could use special comments to exempt specific variables from the restriction.

  int x = 7; /* {non-final} */

With this proposal, the developer accomplishes the same thing with

  var int x = 7;

Since all existing Dart code is still valid under this proposal, I can't see any additional burden for developers coming from Java/JS/C#. Developers wanting to enforce single-assignment carry the burden of their own preference since they have to write the static analysis tool (or compiler option).

Any thoughts or questions? Is such a change acceptable?

[DartBot]

This comment was originally written by [email protected]

---

Removed Type-Defect label.
Added Type-Enhancement, Area-Language, Triaged labels.

[gbracha]

I find this intriguing.

---

Set owner to @gbracha.
Added Accepted label.

[DartBot]

This comment was originally written by [email protected]

---

Very much in the spirit of browser-based (i.e. ECMA-based) languages. Also a feature of the Go language, also by Google.

[anders-sandholm]

Added apr30-triage label.

[anders-sandholm]

Removed apr30-triage label.

[anders-sandholm]

Added triage1 label.

[anders-sandholm]

Removed triage1 label.
Added WontFix label.

[gbracha]

Much as I sympathize, we ultimately decided that it was not worth rocking the boat.