Consider marking @:get as @:pure by default.

[back2dos]

Following the reasoning in haxetink/tink_http#105 it should actually be ok to mark safe methods as @:pure on remoting proxies. This will allow the compiler to optimize away quite a bit of code:

class Data {
  static public var foo:Promise<Foo> = proxy.foo();
}

If nobody accesses Data.foo, then the compiler can DCE the field and because its initialization is pure also eliminate the code and therefore the call on the proxy and the corresponding parser and so forth.

Users could opt out from this via metadata (can be applied to whole class). Using existing compiler semantics @:pure(false) would be the way to go, although I dislike the notation a bit. Perhaps @:unsafe would be more intuitive - although that conflicts with hxcs \o/

[kevinresol]

I think #45 is not affected?

[back2dos]

Oh, totally forgot about that ... :D

Hmm, so this means an unhandled proxy.makePostCall() gets optimized away? I'm not 100% we want that, but if we do, we should document it visibly ^^

[kevinresol]

I am not sure if that was even correct. I just want to be able to put Remote in a coconut model.

[back2dos]

Mhh, I think with recent coconut.data it might be enough to make sure all fields in the remote are final, right?