no type check when using 'this' style constructor parameters

[DartBot]

This issue was originally filed by [email protected]

---

This program gives no type error/warning in frog:

main() {
  print("hello");
  new Foo(5);
  print("done");
}

class Foo {
  String s;
  Foo(this.s) { }
}

But, if I change the constructor syntax to not use the 'this' style shorthand, so it reads like so:

main() {
  print("hello");
  new Foo(5);
  print("done");
}

class Foo {
  String s;
  Foo(String s) : s = s { }
}

then I do get the correct warning:
4:3: warning: type "int" is not assignable to "String"
  new Foo(5);
  ^^^^^^^^^^

Apparently using 'this' in constructor formals is somehow disabling type checking.

[jmesserly]

This is sort of "by design". Those parameters are technically typed to "var". It's like if you wrote "Foo(s): this.s = s {}". The grammar does support adding the type to the constructor too, if you want it: "Foo(String this.s) {}". Then you'll get the correct checking.

What you want here is for a bit of simple type propagation from the field's type to the constructor parameter's type. The Dart language spec doesn't currently use type inference anywhere as part of static type warnings, but I agree it would be really useful. Especially for cases like this where the inference is so simple.

Changing to Enhancement but leaving open.

---

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

[DartBot]

This comment was originally written by [email protected]

---

I see. Thanks for the explanation. Makes sense.

[DartBot]

This comment was originally written by [email protected]

---

I've moved this to a language issue and listed it as a defect until Gilad has a chance to look at it and decide it is something else.

I always thought that Matt's example would create the type error that he is expecting. I also expected that doc tools would show the signature of his initial constructor as Foo(String s) and that the this.s part would just disappear as an implementation detail. If we really want people to specify the type twice - once on the this.s parameter and once on the field, I think that's a significant flaw in the language. Whatever the final choice is, I hope that we can keep the prinicple of say it only once.

To be clear: I believe that the language/spec bug is exactly what Matt was pointing out in his original report against frog. I believe that John is correct that frog is following the current language spec and that this issue is with the spec and not the implementation.

---

Removed Type-Enhancement, Area-Frog labels.
Added Type-Defect, Area-Language labels.
Changed the title to: "no type check when using 'this' style constructor parameters".

[gbracha]

1. This is feature request, not a bug. If you don't like the language semantics, that's fine but that means you want them changed.

2. I think this can be addressed as follows:

Redefine the meaning of initializing formals so that

class Foo {
  T x;
  Foo(this.x);
}

means

class Foo {
  T x;
  Foo(T x'): this.x = x'; // where x' is a fresh variable
}

Technically, no type inference is taking place (which is good; type inference is not something the language wants to rely on).

No promises yet; we'll review and decide soon though.

---

Removed Type-Defect label.
Added Type-Enhancement label.

[gbracha]

Issue #288 has been merged into this issue.

[gbracha]

Added Accepted label.

[gbracha]

Fixed in the 0.08 draft.

---

Added Done label.