For the latest Dart news, visit our new blog at https://medium.com/dartlang .
The Dart standards committee (ECMA TC52) met on January 14th, 2015. The committee discussed several areas where the language could be improved and agreed that these should be investigated in more detail, likely leading to detailed proposals over the next few months.
Configurable Imports
Some libraries only work on the server, or only on the client (in particular, if dart:html has been imported then a server execution is ruled out). There may be added support for some kind of conditional compilation such that different contexts may make different choices about which libraries to import.
Another proposal, which is much more complex and powerful, is concerned with parameterized libraries, e.g., libraries that may take type arguments or other libraries as arguments. Erik mentioned that the conditional compilation feature might already be included in the language, based on the ‘part’ mechanism, and Gilad agreed that that would be worth investigating, too.
Union Types
Union types have been proposed many times, and they have been postponed many times because the flexible nature of the Dart type system makes them less crucial than in some other languages. However, Javascript interoperability creates the greatest pressure for having them, because it is very common to use idioms in Javascript where a meaningful typing in Dart would rely on union types. Other cases could be functions taking an argument of a type T or of type Future<T>, leaving it up to the function to distinguish between the two cases.
First-class functions with different arity is another case. A problem with union types is that they tend to cause parsing conflicts; maybe they could be confined to typedef declarations, but that does not work well with generics; support for local typedefs may help. The operations allowed (when avoiding static type warnings) are just the ones in the common supertype of all operands of the union type operator, i.e., just the operations that are shared among all the types. Avoiding the accidentally shared operations (the ones that are declared independently in several operands) helps greatly avoiding a number of typing related complications.
It should be noted that union types may actually work quite well in Dart, especially because the assignability rules (rather than subtype rules) in the type system allows a value with a union type to be used where any of the operand types can be used.
Generic Methods
Dart does not currently support generic methods (aka polymorphic methods, i.e., methods taking type arguments), because of the strong expectation that they will be supported by type inference, which would add substantial complexity to the language and create conflicts with the basic design of Dart (e.g., the VM might be forced to perform inference at run time at heavy cost, or the reification of types would give user code access to compiler-selected type values, which could change over time due to seemingly remote and insignificant changes in the code). So the generic methods in Dart will not be supported by type inference, all type arguments must be given explicitly or they will be implicitly provided by the compiler as <dynamic..dynamic>. The syntax is not yet settled, and in particular there are ambiguity problems with several proposals (foo(a<b, c>(d)) may be seen as foo(_) or foo(_,_)).
Generalized Tear-Offs
The property extraction mechanism (aka closurization or tear-offs) creates some problems in the language: the current syntax does not work for operators, getters, setters, and constructors, and it is even creating problems for optimization because it is not known before runtime whether ‘a.m’ will need to be executed as a property extraction or as a getter invocation. New syntax is proposed for tear-offs, generally using ‘#’ rather than ‘.’ to separate the receiver and the selector. No particular difficulties are foreseen after an initial review. For backward compatibility, the old syntax and the new will coexist.
Null-Aware Operators
This feature has been requested for a long time! It is simply a small amount of syntactic sugar, but it may be quite convenient and it may be good for code readability. We propose a?.b (the Elvis operator), which just nulls out the result when a is null; a??b which evaluates to the value of b as a default when a evaluates to null; and a ?= b, which sets a to the value of b iff a is null.
Improvements to Type Promotion
This is purely a static type system issue, concerned with the typing of variables for which there is a type test in the preceding control flow. We currently have a few rules about type promotion, deliberately avoiding the highly elaborate versions that so many participants in this debate have requested. These rules are sound, but this is actually not particularly well motivated in a language like Dart. In many cases, users consider the results counterintuitive (“Why can’t it see that x is an int here, I just tested!?”). We may choose to use an unsound approach where the implied intentions of programmers are taken much more for granted, even though there can be exceptions at runtime.
Erik mentioned that if a pluggable type checker could remove certain type warnings then it could be delegated to a pluggable type checker (or several) to perform arbitrarily fancy flow analyses, and do extra type promotion. This means that type promotion in the spec can be very simple, and all the tricky special cases can be handled in a pluggable manner.
Minor Adjustments to the Existing Specification
We may change ‘await throw’ to throw immediately. The rules about type checking usages of objects whose class declares ‘noSuchMethod’ need generalization. The name 'main' should be allowed to be other things than a top-level-function (e.g., a const variable whose value is a suitable closure). Finally, allow doc comments to access imported scope.
Erik mentioned that there is a proposal to revise function type subtyping, and Gilad responded that there may be a need to adjust the specification in this respect, to be discussed at the next meeting.
Configurable Imports
Some libraries only work on the server, or only on the client (in particular, if dart:html has been imported then a server execution is ruled out). There may be added support for some kind of conditional compilation such that different contexts may make different choices about which libraries to import.
Another proposal, which is much more complex and powerful, is concerned with parameterized libraries, e.g., libraries that may take type arguments or other libraries as arguments. Erik mentioned that the conditional compilation feature might already be included in the language, based on the ‘part’ mechanism, and Gilad agreed that that would be worth investigating, too.
Union Types
Union types have been proposed many times, and they have been postponed many times because the flexible nature of the Dart type system makes them less crucial than in some other languages. However, Javascript interoperability creates the greatest pressure for having them, because it is very common to use idioms in Javascript where a meaningful typing in Dart would rely on union types. Other cases could be functions taking an argument of a type T or of type Future<T>, leaving it up to the function to distinguish between the two cases.
First-class functions with different arity is another case. A problem with union types is that they tend to cause parsing conflicts; maybe they could be confined to typedef declarations, but that does not work well with generics; support for local typedefs may help. The operations allowed (when avoiding static type warnings) are just the ones in the common supertype of all operands of the union type operator, i.e., just the operations that are shared among all the types. Avoiding the accidentally shared operations (the ones that are declared independently in several operands) helps greatly avoiding a number of typing related complications.
It should be noted that union types may actually work quite well in Dart, especially because the assignability rules (rather than subtype rules) in the type system allows a value with a union type to be used where any of the operand types can be used.
Generic Methods
Dart does not currently support generic methods (aka polymorphic methods, i.e., methods taking type arguments), because of the strong expectation that they will be supported by type inference, which would add substantial complexity to the language and create conflicts with the basic design of Dart (e.g., the VM might be forced to perform inference at run time at heavy cost, or the reification of types would give user code access to compiler-selected type values, which could change over time due to seemingly remote and insignificant changes in the code). So the generic methods in Dart will not be supported by type inference, all type arguments must be given explicitly or they will be implicitly provided by the compiler as <dynamic..dynamic>. The syntax is not yet settled, and in particular there are ambiguity problems with several proposals (foo(a<b, c>(d)) may be seen as foo(_) or foo(_,_)).
Generalized Tear-Offs
The property extraction mechanism (aka closurization or tear-offs) creates some problems in the language: the current syntax does not work for operators, getters, setters, and constructors, and it is even creating problems for optimization because it is not known before runtime whether ‘a.m’ will need to be executed as a property extraction or as a getter invocation. New syntax is proposed for tear-offs, generally using ‘#’ rather than ‘.’ to separate the receiver and the selector. No particular difficulties are foreseen after an initial review. For backward compatibility, the old syntax and the new will coexist.
Null-Aware Operators
This feature has been requested for a long time! It is simply a small amount of syntactic sugar, but it may be quite convenient and it may be good for code readability. We propose a?.b (the Elvis operator), which just nulls out the result when a is null; a??b which evaluates to the value of b as a default when a evaluates to null; and a ?= b, which sets a to the value of b iff a is null.
Improvements to Type Promotion
This is purely a static type system issue, concerned with the typing of variables for which there is a type test in the preceding control flow. We currently have a few rules about type promotion, deliberately avoiding the highly elaborate versions that so many participants in this debate have requested. These rules are sound, but this is actually not particularly well motivated in a language like Dart. In many cases, users consider the results counterintuitive (“Why can’t it see that x is an int here, I just tested!?”). We may choose to use an unsound approach where the implied intentions of programmers are taken much more for granted, even though there can be exceptions at runtime.
Erik mentioned that if a pluggable type checker could remove certain type warnings then it could be delegated to a pluggable type checker (or several) to perform arbitrarily fancy flow analyses, and do extra type promotion. This means that type promotion in the spec can be very simple, and all the tricky special cases can be handled in a pluggable manner.
Minor Adjustments to the Existing Specification
We may change ‘await throw’ to throw immediately. The rules about type checking usages of objects whose class declares ‘noSuchMethod’ need generalization. The name 'main' should be allowed to be other things than a top-level-function (e.g., a const variable whose value is a suitable closure). Finally, allow doc comments to access imported scope.
Erik mentioned that there is a proposal to revise function type subtyping, and Gilad responded that there may be a need to adjust the specification in this respect, to be discussed at the next meeting.