[dart-misc] Dart Language and Library Newsletter (2017-08-04)

['Florian Loitsch' via Dart Misc]

Github link:
https://github.com/dart-lang/sdk/blob/d94cecba3ceaf6578315764a07292ea0d5e082c3/docs/newsletter/20170804.md
Earlier newsletter:
https://github.com/dart-lang/sdk/blob/d94cecba3ceaf6578315764a07292ea0d5e082c3/docs/newsletter/20170728.md

Dart Language and Library Newsletter

Welcome to the Dart Language and Library Newsletter.
<https://github.com/dart-lang/sdk/blob/master/docs/newsletter/20170804.md#under-active-development>Under
Active Development

This section provides updates to the areas we are actively working on. Many
of these sections have a more detailed explanation in a previous newsletter.
<https://github.com/dart-lang/sdk/blob/master/docs/newsletter/20170804.md#better-organization>Better
Organization

Goal: collect and organize the documents (proposals, ...) the Dart language
team produces.

We are storing all interesting proposals in docs/language/informal (in the Dart
repository <http://github.com/dart-lang/sdk>).

For example, there is a proposal for asserts in initializer lists
assert_init
<https://github.com/dart-lang/sdk/blob/master/docs/language/informal/assert-in-initializer-list.md>.
This feature allows to write basic assertions in the initializer list. The
main use-case is for const constructors, which are not allowed to have
bodies.

For example:

class A {
final int y;
const A(int x) : assert(x < 10), y = x + 1;
}

I will cover some of the proposals in future newsletters. Feel free to send
me requests for specific proposals in that directory.
<https://github.com/dart-lang/sdk/blob/master/docs/newsletter/20170804.md#void-as-a-type>Void
as a Type

Goal: allow void as a type. In particular, make it possible to use it in
generics, such as Future<void>.

Erik (@eernstg) wrote a first proposal for an informal spec, and we are
actively discussing his proposal now. I'm in the process of writing an
easily digestible document on this feature (hopefully for the next
newsletter), but you can also read Erik's (more formal) proposal here:
https://gist.github.com/eernstg/7d79ef7f3e56daf5ce1b7e57684b18c6

We hope to add this proposal to our documentation directory, soon.
<https://github.com/dart-lang/sdk/blob/master/docs/newsletter/20170804.md#updates-to-the-core-libraries>Updates
to the Core Libraries

Goal: clean up the core libraries. Deprecate rarely used classes/methods
and add missing functionality.

Small progress: we wrote CLs (but haven't submitted them yet) for
deprecating SplayTreeMap, SplayTreeSet and DoubleLinkedList. These classes
(and their tests) are migrated to package:collection. The core SDK has been
updated to not use any of these classes anymore.

While we haven't finalized the list of core library changes, here are a few
more likely candidates:

- add map to Map: Iterable<T> map<T>(T Function(K, V) f). This function
makes it possible to iterate over all key-value pairs (similar to
Map.forEach) and build a new iterable out of them.
- add followedBy to Iterable: Iterable<T> followedBy(Iterable<T> other).
With this method, it is finally possible to concatenate two iterables. This
makes the unintuitive [iterable1, iterable2].expand((x) => x) pattern
obsolete: iterable1.followedBy(iterable2).
- add + to List: concatenates two lists: List<T> operator +(List<T>
other). Contrary to followedBy (which is inherited from Iterable), using
+ to concatenate two lists produces a list that is eagerly constructed.
Example: [1, 2] + [3, 4] // -> [1, 2, 3, 4].

These changes are more breaking than the ones we mentioned last week. We
don't know yet how and when we want to land them to avoid the least amount
of disruption.
<https://github.com/dart-lang/sdk/blob/master/docs/newsletter/20170804.md#deferred-loading>Deferred
Loading

The current spec does not allow types to be used across deferred library
imports. This makes sense, when the deferred sources are not known. This
means that users currently have to introduce interfaces for classes that
could just be referenced directly.

// lib1.dartabstract class InterfaceA {
foo();
}// lib2.dartimport 'lib1.dart';class A implements InterfaceA {
foo() => 499;
}// lib3.dartimport 'lib1.dart';import 'lib2.dart' deferred as def;
main() {
InterfaceA a;
def.loadLibrary().then((_) => a = new def.A());
}

Since dart2js and DDC actually know all the sources during compilation,
this boilerplate code feels painful. We are thus looking into alternatives.

We discussed one proposal that suggested to remove deferred loading from
the language entirely and leave it up to the compilers (DDC and dart2js
primarily) to deal with deferred loading. Instead of language syntax, the
compilers would have used annotations and specially recognized functions to
effectively have the same semantics as the current specification. They
could then evolve from there to provide a better experience.

Here is an example, of how this would look like:

import "package:deferred/deferred.dart" show deferred, loadLibrary;
@Deferred("lib1")import "lib1.dart" as lib1;
void main() {
// loadLibrary is specially recognized by dart2js.
loadLibrary(const Deferred("lib1")).then((_) {
/* Assume lib1 has been loaded. */
print(new lib1.A());
});
}

Since the language doesn't provide any guidance, DDC and dart2js could then
implement their own restrictions (potentially using more annotations).

We have discarded this idea, because (among other reasons) the language
front-end is too much involved in deferred loading. For example, it needs
to keep track which types are referenced through (deferred) prefixes. If
the front-end needs to be involved in such a high degree, then we should
specify what exactly it needs to do.

Our plan is now to allow uses of deferred types even when the deferred
libraries haven't been loaded yet. This means that sources of deferred
libraries must be available during compilation of non-deferred functions:

/// lib1.dartclass A {}
/// lib2.dartexport "lib1.dart" show A;
/// main.dartimport "lib1.dart";import "lib2.dart" deferred as def;
main() {
print(new A() is def.A); // Requires knowledge of `def.A`.
}

While this change is clearly breaking (and we know of a few programs that
created the deferred libraries in the main library), in practice, deferred
loading is mainly used as a deployment tool to cut down the size of the
initial payload. At that time all sources are available.

The main tool that is affected by the new semantics is dart2js. We are
tracking work on this feature in dart2js here:
https://github.com/dart-lang/sdk/issues/29903

Once dart2js has the resources to implement and experiment with the new
semantics we will provide updates.