Dart Language and Library Newsletter

2017-08-11 @floitschG

Welcome to the Dart Language and Library Newsletter.

Follow Ups

Void Arrow Functions

As mentioned in an earlier newsletter, void arrow functions with non-void expressions (as in void foo() => x++) are supported with Dart 1.24. However, this feature still has to be used with care. Due to a temporary limitation of the type inference in strong mode, returning a non-void expression might not work as expected.

For example:

var f = new Future(() { doSomethingAsynchronously(); };
f.catchError((e) => errorCounter++);

The type-inference algorithm currently infers Null for the generic type of the Future. Functions without return indeed return null, so technically, that type is correct. However, the catchError signature requires the provided function to return the same type as the function it is attached to. In this case, f is a Future<Null>, but errorCounter++ is an int. Since int is not Null this throws at runtime.

As mentioned in earlier newsletters, we are actively working on generalizing void, and once it is supported the inferred type of f will be Future<void>. The catchError closure then would just need to be a subtype of void Function() which would work fine for (e) => errorCounter++. Until then, be careful where you use the void arrow function syntax.

Deferred Loading

Last time we discussed our plans to allow the use of deferred types even when the deferred libraries haven't been loaded yet. This makes programs, like the following, possible:

/// lib1.dart
class A {}

/// lib2.dart
export "lib1.dart" show A;

/// main.dart
import "lib1.dart";
import "lib2.dart" deferred as def;

main() {
  print(new A() is def.A);  // Requires knowledge of `def.A`.
}

A follow-up mail questioned the need for such a big hammer. In reality, most programs just want to use the deferred type as a type annotations:

main() async {
  def.A a; // <-- Illegal today.
  await def.loadLibrary();
  a = new def.A();
}

Is there a simpler / better solution that would allow patterns like these, but not require full knowledge of the deferred types?

It turns out, that the answer is likely “no”. In fact, we find that, because of type inference, even the current behavior is already counterintuitive and should be fixed. That is, even without allowing more uses of deferred types, programs don't behave as expected:

// ------ def.dart
class Box<T> {
  T value;
  Box(this.value);
}

// ------ main.dart
import "def.dart" deferred as def;

main() async {
  await def.loadLibrary();
  var box = new def.Box(499);
  var list = [box.value];
}

With type inference, users expect three things to happen:

box is of type def.Box<int>.
the generic type of new def.Box(499) is Box<int>, as if the user had written new def.Box<int>(499).
list is of type List<int>.

Without access to the deferred sources, none of these expectations is met. Since type inference runs at compile-time, box has to be treated like dynamic. There is simply not more information available. For similar reasons, box must be of type Box<dynamic>. Since the invocation of the constructor happens at runtime (where no type-inference happens), the missing generic type is dynamically filled with dynamic.

Finally, list must be of type List<dynamic> since box.value is a dynamic invocation, and the type inference doesn't know that the returned value will be of type int.

This small example shows that type inference requires knowledge of the deferred types to do its job. This means that all sources must be available when compiling individual libraries. Once that‘s the case it doesn’t make sense to restrict the use of deferred types. They don't take up much space (which is the usual reason for deferring libraries), and giving full access to them removes a lot of boilerplate or dynamic code.

Const Functions

The language team discussed the possibility of supporting const functions.

class A {
  final Function(e) callback;
  const A(this.callback);
}

// Provide a `const` function to `A`'s constructor.
const x = const A(const (e) { print(e); });

// Default values have to be `const`.
void sort(List<int> list, [int compare(int x, int y) = const (x, y) => x - y) {
  ...
}

This feature doesn‘t add new functionality. Users can already now write a static function with the same body and use its tear-off (which is guaranteed to be const) in all of these locations. However, it’s more convenient to write functions closer to where they are needed. For example, the classic map.putIfAbsent(x, () => []) allocates a new function (a cheap operation, but still), whereas map.putIfAbsent(x, const () => []) would always reuse the same function.

Sidenote: in dart2js, many const values (not functions) are allocated at initialization, which shifts some execution time to the beginning of the program where many teams already struggle with performance. In the current dart2js version it's thus not always beneficial to make objects const.

Shadowing of Core Libraries

When deprecating core library classes (like SplayTreeMap) we intend to minimize the cost to our users. We copy the deprecated classes to packages (in this case collection) so that users just need to change their imports from dart:collection to package:collection. However, that means that programs that import dart:collection and package:collection at the same time now see the same class twice; once from each import. Which class should Dart now use? Is this an error?

For “normal” imports (not dart:), the rules are simple: an ambiguous reference is an error. There is no good way to decide between class A of package pkg1 or pkg2. With core libraries, things get a bit more complicated: whereas upgrading packages is a user-triggered action (with the fallback to revert to the previous pubspec.lock), upgrading the SDK should generally be safe. As a consequence, Dart considers core libraries as less important. That is, shadowing a class from any dart: library is ok. Importing dart:collection and package:collection/collection.dart is thus fine and will not lead to errors. It's still good practice to use show and hide to make the intention completely clear.

We are still unsure how to handle cases when the user explicitly used show to import a specific core library type:

import 'dart:collection' show SplayTreeMap;
import 'package:collection/collection.dart';