Replace 'Dynamic' with 'var'

[rakudrama]

It is surprising that 'var' cannot be used in the position of the return type of a method or getter.
Multiple people find this surprising which indicates that it is a widespread problem.

I recently had to translate a bunch of fields to getters:

   final int foo;
   final var bar;
-->
   int get foo() => ...;
   var get bar() => ...;

This doesn't work because there is a type called Dynamic that is confusingly the type associated with the keyword 'var'.
The correct translation is

   int get foo() => ...;
   get bar() => ...;
or
   int get foo() => ...;
   Dynamic get bar() => ...;

The thing that feels right is wrong and both of the right things look worse that the wrong thing.
I think having 'var' and 'Dynamic' is a mistake and we should make 'var' behave like 'Dynamic' in this context and in parameterized types.

Further evidence comes from a discussion from a month ago:

---

Jim:

I was just surprised (for the nth time) to find that 'var' is not allowed as a return type for functions and methods in dart. I often like to use var when I'm half-way through moving code from dynamically typed to statically typed for those areas that are explicitly still dynamic. I realize that I could use "Dynamic" instead, but that feels very awkward - and it doesn't feel consistent with the fact that I can use var for the parameter positions. I understand the theoretical rationales for this choice. My question is about whether or not this is the most useful behavior for developers.

Here's an example of the kind of place that I hit this and get confused as my code evolves:

// starting truly dynamic
createNode(parent, kind) => ...;

// 1st step towards types - works in Dart
createNode(var parent, String kind) => ...;

// blows up - but feels consistent with the code above
var createNode(var parent, String kind) => ...;

Can we please allow 'var' to be used as a type name and remove the much more verbose 'Dynamic' from the language? Unless we want to make a much more radical change to types in dart away from the current C-style syntax, I believe that this would make our syntax and semantics feel both simpler and more consistent to most developers.

If we want to keep this behavior, then the VM and compilers need to be updated to give good error messages for this very common and easy to make mistake - right now they blow-up with a hoard of confusing messages instead. And the editor should get a quick fix button to change 'var' to either 'Dynamic' or to erase it when it breaks the grammar.

Thanks - Jim

---

Vijay:

I'd like to add a general +1 to Jim's note below on var vs Dynamic.

My general style is to use types for return values from the start, so I haven't hit this so much. This weekend, I started teaching my 9 year old programming (with Dart of course :-)), and I made a conscious effort to avoid types. I kept finding myself writing:

var foo (n) { ... }

Yes, I'll just get used to omitting the "var", but I agree with Jim - it's surprising that this doesn't work.

Cheers,

Vijay

[gbracha]

I'm sorry you all refuse to understand the distinction between introducing a declaration and a type, but it exists all the same. We can call the type Dynamic something else (and bug 944 is about that) but confusing matters is a bad idea.

---

Set owner to @gbracha.
Added Accepted label.

[rakudrama]

Humor me with the following thought experiment:

1. Create a new language called Dart' by taking Dart and striking out any grammar production with the keyword 'var'.
2. Convert Dart programs to Dart' programs by replacing 'var' with 'Dynamic'.

Unless I am missing something, the converted Dart' programs should behave just like the original Dart programs.

1. In Dart', rename the type 'Dynamic' to 'var'.

The difference between Dart and Dart' is that in Dart' it is sometimes necessary to use a type to introduce a declaration, whereas Dart has an extra feature using the 'var' keyword for the purpose.
Our accumulated experience indicates that Dart', the simpler of the two languages, might be easier to use and explain to others.

It is not necessary to confuse the distinction between 'introducing a declaration' and 'a type'. A type may be used to 'introduce a declaration' as in 'int x;', and now there is no distinction between 'var x;' and 'int x;'.

[gbracha]

final var x;

[rakudrama]

I'm not sure of your point.

neither of
 final var x = ...;
 final Dynamic x = ...;
look at all strange to me.

(I would still permit the type to be omitted so 'final x = ...' would be allowed.)

[gbracha]

final var x; would make sense if you allowed final var x: int; which makes
it clear what is going on, and why var is not a type. As its stands it
looks very strange to some people. As does

var get f() => 3;

and for that matter

var f(x){return x;}

I don't see anyone complaining about final not being a type. The confusion
is rooted in the C syntax, and I am not keen to use one confusion to
introduce another.

[vsmenon]

I'm sorry you all refuse to understand the distinction between introducing a declaration and a type, but it exists all the same.

Gilad,

I think there are two reasons for this:

(1) The language encourages this confusion by letting us use var and types interchangeably in most situations. Even though we know they are different, we often forget. :-)

(2) "Dynamic" is out of sight and out of mind. A quick grep of all our samples as well as the frog compiler shows 1 use of Dynamic in about 100,000 lines of code (and that one use could be replace by var).

Cheers,

Vijay

[gbracha]

Vijay,

Oddly, I was going to raise that very point. It doesn't matter that the
name Dynamic is long or unfamiliar; on the contrary, it encourages people
to avoid using it explicitly, which is the intent. It is bad style to
explicitly mark a function as returning Dynamic (or var, or Any or whatever
you choose to call it). It is very rare that you need to be aware of it
(only when instantiating a generic with multiple type arguments where some
are known and some are not).

So why are we wasting time on it?

[vsmenon]

So why are we wasting time on it?

Because the current confusion is causing programmers (jimhug, sra, me) to waste time when writing Dart code. It's only fair we waste your time as well. :-)

Cheers,

Vijay

[ghost]

I think the confusion about the role of 'var' is caused by the shortcut when defining a variable. Instead of "int x" we should be writing "var int x". In Dart, the following is (or will be legal):

var x;
final x = 0;
const x = 0/

and with types:

int x; // means var int x;
final int x = 0;
const int x = 0;

Making var, final or const to be a type does not makes much sense to me and I believe would be very surprising to many programmers (it would be to most of us in MTV).

I understand that there are practical problems that this request is attempting to solve. I do not think that is the right way of solving it, though. IMHO, the solution to Jim's problem (locate all untyped declarations) is easily implementable in the tools, and should be done there.

P.S.: "final var x" is not legal Dart syntax.

[anders-sandholm]

Added this to the M1 milestone.

[DartBot]

This comment was originally written by @tomyeh

---

If type casting is implemented, Dynamic can be removed completely (use Object or var instead). For example,

void f(List<Object> foos) {
  for (Object o in foos)
    (o as Foo).doIt();
}

[gbracha]

After a long discussion, we decided to close this bug. However, the function dynamic() used for casting will be replaced with the 'as' operator. Below is a detailed discussion of the considerations that led to this decision:

The proposal is not really about renaming Dynamic, but about changing the meaning of 'var'. To make the point clear, I will start with a discussion of what 'var' means today. To do this, I will deliberately start from the semantics, with a concrete syntax that is not Dartesian, and migrate to one that is. Afterwards, we'll deal with the question of why we should not change that meaning.

Semantically, variable declaration specifies the following:

Whether the variable is mutable or immutable; what the variable's name is; and what its type is. A clean, unambiguous syntax captures this structure very directly:

varDecl -> mutabilitySpeciifer varName varType
mutabilitySpecifier -> mutable | immutable
varName -> identifier
varType -> : typeExpression

We'll throw in semicolons as terminators as well. So, we could write

mutable v1: int;
immutable v2: String;

Now, lets replace those verbose, if unambiguous, keywords 'mutable' and 'immutable' with something more familiar: 'var' for mutable and 'final' for immutable:

var v1: int;
final v2: String;

Now we make the type annotation optional; if the type isn't specified we mean the unknown type, Dynamic. So we can also write

var v3; // really var v3: Dynamic;
final v4; // really final v4: Dynamic

Next, we'll move to a C-style type specification; again, trading clarity for familiarity:

var int v1;
final String v2;
var v3; // really var Dynamic v3;
final v4; // realy final Dynamic v4;

Lastly, but crucially, we'll decide that variables are mutable by default (even though it is in a sense the wrong default for two reasons: immutable variables are more common (at least for fields) and we should encourage functional style).

This last change only works if there is a type specifier, otherwise we cannot distinguish variable declaration from variable usage. So we can write

int v1; // shorthand for var int v1;
final String v2;
var v3; // really var Dynamic v3; or just Dynamic v3;
final v4; // really final Dynamic v4;

At this point, our various shortcuts have brought us to the point where the keyword 'var', intended to introduce a mutable variable, appears syntactically in the same position as a type annotation. Readers who don't think this through become confused and decide that 'var' is a type, leading to the proposal of renaming Dynamic to var.

Hopefully, the above makes it clear that 'var' is no more a type than 'final' is. However, that alone would probably not have caused this proposal to be rejected.

The deciding factor is readability.

So, what could possibly go wrong? If we decide that 'var' is a type, we must allow it in every position where a type is currently allowed:

var f(x) => 42;
var h(var z){return 3;}
typedef var g(var x);
final var v5;
e is var;
e is! var;
e as var;

All of the above are confusing and undermine program readability.

In practice, there is rarely a need to write the type Dynamic explicitly, and it is bad style to do so unless it is essential (which can happen when using multi-argument generics, e.g., Map<String, Dynamic>), as it makes code more verbose without adding information.

---

Added WontFix label.