Newsletter 2017-08-18.

docs/newsletter/20170818.md

+# Dart Language and Library Newsletter
+2017-08-18
+@floitschG
+
+Welcome to the Dart Language and Library Newsletter.
+
+## If you missed it
+Did you know that you can write trailing commas to arguments and parameters? This feature was added to the specification about a year ago.
+
+It's main use-case is to unify parameter and argument lists that span multiple lines. For example, [Flutter] uses it extensively to keep tree-like instantiations nicely aligned:
+
+[Flutter]: http://flutter.io
+
+``` dart
+    return new Material(
+      // Column is a vertical, linear layout.
+      child: new Column(
+        children: <Widget>[
+          new MyAppBar(
+            title: new Text(
+              'Example title',
+              style: Theme.of(context).primaryTextTheme.title,
+            ),
+          ),
+          new Expanded(
+            child: new Center(
+              child: new Text('Hello, world!'),
+            ),
+          ),
+        ],
+      ),
+```
+
+Note how every argument list ends with a comma. The `dartfmt` tool knows about these trailing commas and ensures that the individual entries stay on their own lines so that it is easy to move them around with cut and paste.
+
+Recently, we also updated the specification to allow trailing commas in `assert`s. This makes the syntax of `assert`s more consistent with function calls.
+
+### Function Type Syntax
+A few months ago, we added a new function type syntax to Dart (we mentioned it in our first newsletter).
+
+``` dart
+// Examples:
+typedef F = void Function(int);  // A void function that takes an int.
+
+void foo(T Function<T>(T x) f) {  // foo takes a generic function.
+  ...
+} 
+
+class A {
+  // A has a field `f` of type function that takes a String and returns void.
+  void Function(String) f;
+}
+```
+
+Before we added the new function-type syntaxes, we evaluated multiple options. In this section I will summarize some of the discussions we had.
+
+#### Motivation
+The new function-type syntax intends to solve three issues:
+
+1. the old `typedef` syntax doesn't support generic types.
+2. the old function syntax can't be used for fields and locals.
+3. in the old syntax, providing only one identifier in an argument position is interpreted as name and not type. For example: `typedef f(int);`  is *not* a typedef for a function that expects an `int`, but for a function that expects `dynamic` and names the argument "int".
+
+With Dart 2.0 we will support generic methods, and also generic closures. This means that a function can accept a generic function as argument. We were lacking a way to express this type.
+
+Dart 1.x has two ways to express function types: a) an inline syntax for parameters and b) `typedef`s.
+
+It was easy to extend the inline syntax to support generic arguments:
+
+
+``` dart
+// Takes a function `factoryForA` that is generic on T.
+void foo(A<T> factoryForA<T>()) {
+  A<int> x = factoryForA<int>();
+  A<String> x = factoryForA<String>();
+}
+```
+
+However, there was no easy way to do the same for `typedef`s:
+
+``` dart
+typedef A<T> FactoryForA<T>();// Does *not* do what we want it to do:
+
+FactoryForA f;  // A function that returns an `A<dynamic>`.
+FactoryForA<String> f2;  // A function that returns an `A<String>`.
+f<int>();  // Error: `f` is not generic.
+```
+
+We had already used the most consistent place for the generic method argument as a template argument to the `typedef` itself. If we could go back in time, we could change it as follows:
+
+``` dart
+typedef<T> List<T> TemplateTypedef();
+TemplateTypedef<int> f;  // A function that returns a List<int>.
+TemplateTypedef f;  // A function that returns a List<dynamic>.
+
+typedef List<T> GenericTypedef<T>();
+GenericTypedef f;  // A function that is generic.
+List<int> ints = f<int>();
+List<String> strings = f<String>();
+```
+
+Given that this would be a breaking change we explored alternatives that would also solve the other two issues. In particular the new syntax had to work for locals and fields, too.
+
+First and foremost the new syntax had to be readable. It also had to solve the three mentioned issues. Finally, we wanted to make sure, we didn't choose a syntax that would hinder future evolution of the language. We made sure that the syntax would work with:
+- nullability: the syntax must be nullable without too much hassle:
+  ``` dart
+   (int)->int?;  // A function that is nullable, or that returns a nullable integer?
+   Problem disappears with <-
+   int <- (int)? ; vs int? <- (int) 
+  ```
+- union types (in case we ever want them).
+
+
+#### Common Characteristics
+For all the following proposals we had decided that the arguments could either be just the type, or optionally have a name. For example, `(int)->int` is equivalent to `(int id)->int`. Especially with multiple arguments of the same type, providing a name can make it much easier to reason about the type: `(int id, int priority) -> void`. However, type-wise these parameter names are ignored.
+
+All of the proposals thus interpret single-argument identifiers as types. This is in contrast to the old syntax where a single identifier would state the name of the parameter: in `void foo(bar(int)) {...}` the `int` is the name of the parameter to `bar`. This discrepancy is hopefully temporary, as we intend to eventually change the behavior of the old syntax.
+
+##### Right -> Arrow
+Using `->` as function-type syntax feels very natural and is used in many other languages: Swift, F#, SML, OCaml, Haskell, Miranda, Coq, Kotlin, and Scala (with =>).
+
+Examples:
+``` dart
+typedef F = (int) -> void;  // Function from (int) to void.
+typedef F<T> = () -> List<T>;  // Template Typedef.
+typedef F = <T>(T) -> List<T>;  // Generic function from T to List<T>.
+```
+
+We could even allow a short form when there is only one argument: `int->int`.
+
+We have experimented with this syntax: [https://codereview.chromium.org/2439573003/]
+
+Advantages:
+- easy to learn and familiar to many developers.
+- could support shorthand form `int->int`.
+
+Open questions:
+- support shorthand form?
+- whitespace. Should it be `(int, int) -> String` or `(int, int)->String`, etc.
+
+Disadvantages:
+- Relatively late token. The parser would have to do relatively big lookaheads.
+- Works badly with nullable types:
+  ``` dart
+  typedef F = (int) -> int?;  // Nullable function or nullable int?
+  // Could be disambiguated as follows:
+  typedef F = ((int)->int)?;   // Clearly nullable function.
+  ```
+
+
+##### Left <- Arrow
+This section explores using `<-` as function-type syntax. There is at least one other language that uses this syntax: [Twelf](http://www.cs.cmu.edu/~twelf/guide-1-2/twelf_3.html).
+
+Examples:
+``` dart
+typedef F = void <- (int);  // Function from (int) to void.
+typedef F<T> = List<T> <- ();  // Template Typedef.
+typedef F = List<T> <- <T>(T);  // Generic function from T to List<T>.
+```
+
+Could also allow a short form: `int<-int`.  (For some reason this seems to read less nicely than `int->int`.)
+
+We have experimented with this syntax: [https://codereview.chromium.org/2466393002/]
+
+Advantages:
+- return value is on the left, similar to normal function signatures. This also simplifies `typedef`s, where the return value is more likely to stay on the first line.
+- faster to parse, since the `<-` doesn't require a lot of look-ahead.
+- relatively similar to `->`.
+- no problems with nullable types:
+  ``` dart
+  typedef F = int <- (int)?;  // Nullable function.
+  typedef F = int? <- (int);  // Returns nullable int.
+  ```
+
+Open Questions:
+- whitespace?
+- support shorthand form?
+
+Disadvantages:
+- `<-` is ambiguous: `x<-y ? foo(x) : foo(y)  // if x < (-y) ...`.
+- Not as familiar as `->`.
+
+##### Function
+Dart already uses `Function` as general type for functions. It is relatively straightforward to extend the use of `Function` to include return and parameter types. (And no: it's not `Function<int, int>` since that wouldn't work for named arguments).
+
+
+``` dart
+typedef F = void Function(int);  // Function from (int) to void.
+typedef F<T> = List<T> Function();  // Template Typedef.
+typedef F = List<T> Function<T>(T);  // Generic function from T to List<T>.
+```
+
+This form does not allow any shorthand syntax, but fits nicely into the existing parameter syntax.
+
+Before we accepted this syntax, we had experimented with this syntax: [https://codereview.chromium.org/2482923002/]
+
+Advantages:
+- very similar to the syntax of the corresponding function declarations.
+- no ambiguity.
+- (almost) no new syntax. That is, the type can be immediately extrapolated from other syntax.
+- no open questions wrt whitespace.
+- symmetries with existing use of `Function`:
+  ``` dart
+  Function f;  // a function.
+  Function(int x) f;  // a function that takes an int.
+  double Function(int) f;  // a function that takes an int and returns a double.
+  ```
+
+Disadvantages:
+- longer.
+
+##### Conclusion
+We found that the `Function`-based syntax fits nicely into Dart and fulfills all of our requirements. Due to its similarity to function declarations it is also very future-proof. Any feature that works with function declarations should work with the `Function`-type syntax, as well.
+