Allow fine grain control over checked-mode behavior in production and development

[DartBot]

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

---

I'm writing a framework that does RPC. Something like this:

someRpcFunction(Foo f, Bar b) { ... }

exportForRpc(someRpcFunction);

The framework calls the function is using Function.apply() after deserializing the arguments.

Dart will check the parameter types, but only in checked mode. This gives a false sense of security. To get the same checking in production mode, you have to check the types again:

rpcFunction(Foo f, Bar b) {
  if (!(f is Foo) || !(b is Bar)) {
    throw "function called with bad arguments";
  }
}

This is redundant and makes it easy to make mistakes.

So, it would be nice if there were a @­checked annotation to keep argument type-checking on all the time for a particular function, and a way to test whether a given function is @­checked. Then the framework can ensure that all functions exported for RPC have their arguments checked all the time.

[lrhn]

Added Type-Enhancement, Area-Language, Triaged labels.

[DartBot]

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

---

A second use case would be deserialization:

class Foo {
  num a;
  String b;
  Foo(this.a, this.b);

  factory Foo.fromJson(Map data) {
    return new Foo(data["a"], data["b"]);
  }
}

If "a" and "b" are swapped, nothing checks the types in production mode, so the user will have to write redundant checking code. A @­checked annotation on the constructor would fix this.

[DartBot]

This comment was originally written by @Emasoft

---

I agree. Also it should be possible to FORCE type checking even at runtime when Dart is run natively in Dartium.

[gbracha]

I think it would be very nice to have more fine grain control over checked mode - both to turn it on and to turn it off. I'm not fond of using annotations for semantic effects - this is a slippery slope. I'm changing the summary to avoid overspecifying a solution.

---

Set owner to @gbracha.
Added Accepted label.
Changed the title to: "Allow fine grain control over checked-mode behavior in production and development".

[munificent]

Strong mode does do this checking. When the VM and dart2js fully support strong mode at runtime, that will address this too.