Skip to main content

Dart Language Evolution Discussed in Ecma TC52

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.

Comments

Popular posts from this blog

Const, Static, Final, Oh my!

Posted by Seth Ladd

(This is an "oldie but a goodie" misc@dartlang.org post originally written by Bob Nystrom. It is being posted here as the explanations still ring true.)

Bob writes:


"static", "final", and "const" mean entirely distinct things in Dart:

"static" means a member is available on the class itself instead of on instances of the class. That's all it means, and it isn't used for anything else. static modifies *members*.

"final" means single-assignment: a final variable or field *must* have an initializer. Once assigned a value, a final variable's value cannot be changed. final modifies *variables*.

"const" has a meaning that's a bit more complex and subtle in Dart. const modifies *values*. You can use it when creating collections, like const [1, 2, 3], and when constructing objects (instead of new) like const Point(2, 3). Here, const means that the object's entire deep state can be determ…

Dart 1.12 Released, with Null-Aware Operators and more

Dart 1.12.0 is now released! It contains the new null-aware operators language feature, and enhancements to pub, Observatory, dartdoc, and much more.

Null-aware operators

The new null-aware operators help you reduce the amount of code required to work with references that are potentially null. This feature is a collection of syntactic sugar for traversing (potentially null) object calls, conditionally setting a variable, and evaluating two (potentially null) expressions.

Click or tap the red Run button below to see them in action.

??

  if null operator. `expr1 ?? expr2` evaluates to `expr1` if not `null`, otherwise `expr2`.


??=

  null-aware assignment. `v ??= expr` causes `v` to be assigned `expr` only if `v` is `null`.

x?.p

  null-aware access. `x?.p` evaluates to `x.p` if `x` is not `null`, otherwise evaluates to `null`.

x?.m()

  null-aware method invocation. `x?.m()` invokes `m` only if `x` is not `null`.

Learn more about Dart's null-aware operators in our Language Tour.

.packages fi…

The new AdWords UI uses Dart — we asked why

Google just announced a re-designed AdWords experience. In case you’re not familiar with AdWords: businesses use it to advertise on google.com and partner websites. Advertising makes up majority of Google’s revenue, so when Google decides to completely redo the customer-facing front end to it, it’s a big deal. The Dart team is proud to say that this new front end is built with Dart and Angular 2. Whenever you asked us whether Google is ‘even using Dart for anything,’ this is what we had in mind but couldn’t say aloud. Until now. We asked Joshy Joseph, the primary technical lead on the project, some questions. Joshy is focusing on things like infrastructure, application latency and development velocity, so he’s the right person to ask about Dart.Q: What exactly did we launch on Monday?It’s a complete redesign of the AdWords customer experience that is rolling out slowly as a test to a small initial set of advertisers. The most noticeable thing is probably the Material Design look and f…