Decision
- Default type stays
dynamic
:paramName in interop calls with named arguments is deprecated in favor of the new syntax.paramName. This new syntax allows to syntactically recognize a cll with named arguments without knowing the type of target, thus allowing proper code emission in the dynamic case.
.field for field access is deprecated in favor of .-field which is already supported. This decision follows the same goal as the previous one: allowing good code emission even when types are unknown.
Original description
"Stern warnings" are way more likely to lead to weird errors than Clojure's reflection warnings, that's why they should be errors.
This is of concern only for interop code. Dynamism of pure Clojure is not affected. It's just about making accidental use of dynamic interop (which leads to bizarre error or behaviors) impossible.
Early in ClojureDart development we relied extensively on Dart dynamic type because the compiler was completely oblivious to types. Currently we try to avoid relying on the Dart compiler guessing types and try to produce type-explicit code. Dynamic calls used to be the norm, now they are errors.
So here I propose several related changes:
- default type will now be
Object? and not dynamic
- in places where
dynamic semantics would be really wanted the user would have to explicitly write ^dynamic
- failure to resolve a member will be be an error unless the target is typed
dynamic.
Decision
dynamic:paramNamein interop calls with named arguments is deprecated in favor of the new syntax.paramName. This new syntax allows to syntactically recognize a cll with named arguments without knowing the type of target, thus allowing proper code emission in the dynamic case..fieldfor field access is deprecated in favor of.-fieldwhich is already supported. This decision follows the same goal as the previous one: allowing good code emission even when types are unknown.Original description
"Stern warnings" are way more likely to lead to weird errors than Clojure's reflection warnings, that's why they should be errors.
This is of concern only for interop code. Dynamism of pure Clojure is not affected. It's just about making accidental use of
dynamicinterop (which leads to bizarre error or behaviors) impossible.Early in ClojureDart development we relied extensively on Dart
dynamictype because the compiler was completely oblivious to types. Currently we try to avoid relying on the Dart compiler guessing types and try to produce type-explicit code. Dynamic calls used to be the norm, now they are errors.So here I propose several related changes:
Object?and notdynamicdynamicsemantics would be really wanted the user would have to explicitly write^dynamicdynamic.