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.

Popular posts from this blog

Dart in 2016: The fastest growing programming language at Google, 2nd fastest growing in TIOBE Index

Dart was the fastest growing programming language at Google in 2016 with millions of lines of code written. It also made it to TIOBE Index Top 20 this month (see TIOBE's methodology ). It takes time to build something as ambitious as Dart and, in some ways, Dart is still in its infancy. But we're glad the hard work is starting to pay off. Many thanks to our amazing community! We're going to celebrate by ... releasing 1.22 next week (as per our usual 6 week release schedule).

AngularDart is going all Dart

Until now, the multiple language flavors of Angular 2 were written as TypeScript source, and then automatically compiled to both JavaScript and Dart. We're happy to announce that we’re splitting the Angular 2 codebase into two flavors – a Dart version and a TypeScript/JavaScript version – and creating a dedicated AngularDart team. This is amazing news for Dart developers because: The framework will feel more like idiomatic Dart. It will make use of Dart features that couldn't work with the TypeScript flavor. It will be faster. This is equally great news for our TypeScript and JavaScript developers, by the way. Cleaner API, performance gains, easier contributions. Read more on the Angular blog. Angular 2 for Dart is used by many teams at Google. Most famously by the AdWords team, but many other Google teams build large, mobile-friendly web apps. Some of the top requests from these teams were: make the API feel like Dart, provide a faster edit-refresh cycle, and

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 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