Added informal generic method syntax and generic function type specs.

docs/language/informal/generic-function-type-alias.md

+# Feature: Generic Function Type Alias
+
+**Status**: Implemented.
+
+**This document** is an informal specification of a feature supporting the
+definition of function type aliases using a more expressive syntax than the
+one available today, such that it also covers generic function types. The

[Lasse Reichstein Nielsen, 2017/07/11 11:13:52]

Consider using "generic-function types" or "types of generic functions" t avoid
ambiguity.

[eernst, 2017/07/11 15:50:04]

Added a paragraph making the distinction between the two groupings "(generic
function) type" and "generic (function type)", and explicitly mentioning
`generic-function type`.

+feature also introduces syntax for specifying function types directly, such
+that they can be used in type annotations etc. without going via a
+`typedef`.
+
+**This feature** introduces a new syntactic form of typedef declaration
+which includes an identifier and a type, connecting the two with an equals
+sign, `=`. The effect of such a declaration is that the name is declared to
+be an alias for the type. Type parameterization may occur in the
+declaration itself, as well as in the declared type. This feature also

[Lasse Reichstein Nielsen, 2017/07/11 11:13:53]

I'm not sure I understand that. I think it's being too "generic" in how it's
talking about things. :)

Is it saying that the typedef can be generic (parameterized by type), and the
function type itself can be the type of a generic function (the function type is
not parmeterized, it is the type of a generic function, big difference :).

Consider removing the sentence and say that this allows making an alias for a
the types of generic functions. The typedef-parameterization is not new, so you
don't need to mention it.

[eernst, 2017/07/11 15:50:04]

Exactly.
I added references to the terminology introduced in the new paragraph which at
least creates a connection to known terminology above, and to examples given
later. I think it makes sense to mention parameterized typedefs even though the
old syntax also supported that notion, because `typedef F<X> = ..` is new
syntax.

Besides, I'm sure lots of readers could be a little bit confused about the
meaning of the old syntax, e.g., `typedef void f<T>(T t);`.

+introduces syntax for specifying function types directly, using a syntax
+which is similar to the header of a function declaration.
+
+The **motivation** for adding this feature is that it allows developers to
+specify generic function types at all, and to specify function types
+everywhere a type is expected. That includes type annotations, return types,
+actual type arguments, and formal type parameter bounds. Currently there is
+no way to specify a function type directly in these situations. Even in the
+case where a function type *can* be specified (such as a type annotation for
+a formal parameter) it may be useful for readability to declare a name as an
+alias of a complex type, and use that name instead of the type.
+
+## Examples
+
+Using the new syntax, a function type alias may be declared as follows:
+
+```dart
+typedef F = List<T> Function<T>(T);
+```
+
+This declares `F` to be the type of a function that accepts one type
+parameter `T` and one value parameter of type `T` whose name is
+unspecified, and returns a result of type `List<T>`. It is possible to use
+the new syntax to declare function types that we can already declare using
+the existing typedef declaration. For instance, `G` and `H` both declare
+the same type:
+
+```dart
+typedef G = List<int> Function(int); // New form.
+typedef List<int> H(int i); // Old form.
+```
+
+Note that the name of the parameter is required in the old form, but the
+type may be omitted. In contrast, the type is required in the new form, but
+the name may be omitted.
+
+The reason for having two ways to express the same thing is that the new
+form seamlessly covers non-generic functions as well as generic ones, and
+developers might prefer to use the new form everywhere, for improved
+readability.
+
+*We may deprecate the old form after a while, or we may choose
+to keep it, because it is more concise. We may even change the old form to
+allow omitting the name and not the type when only one identifier is
+specified, if this is not too much of a breaking change. As an intermediate
+step we could change the old form to always require both the type and the
+name, such that no type expressions will silently change meaning.*

[Lasse Reichstein Nielsen, 2017/07/11 11:13:53]

This is all speculative, not descriptive, so it doesn't help anybody who wants
to implement the feature. Either remove it or move it to separate section at the
end where it doesn't obscure the actual specification.

[eernst, 2017/07/11 15:50:04]

Deleted it.

+
+There is a difference between declaring a generic function type and

[Lasse Reichstein Nielsen, 2017/07/11 11:13:53]

here maybe say "between declaring the type of a generic function and declaring a
typedef ...."

[eernst, 2017/07/11 15:50:04]

With the changes earlier in this document, the phrase 'generic function type'
has been introduced explicitly. I suppose we'll just create confusion by using a
different phrase here to mean exactly the same thing. The explanation that
spells out exactly what `generic function type` means is right here in line
68++, anyway.

+declaring a typedef which takes a type argument. The former is a
+declaration of a single type which describes a certain class of runtime
+entities: Functions that are capable of accepting some type arguments as
+well as some value arguments, both at runtime. The latter is a type-level
+function: It accepts a type argument at compile time and returns a type,

[Lasse Reichstein Nielsen, 2017/07/11 11:13:53]

"type-level function" uses "function" in a too-overloaded way - this is a
document about function types, let's do function-type-functions as well, then
we're sure to have lost all readers. 
That is: No meta!

[eernst, 2017/07/11 15:50:05]

But it _is_ a type-level function, and a bunch of people (e.g., anyone who has
been looking at Scala typing) would consider that concept to be natural.

However, I replaced the phrase 'type-level function' by 'compile-time mapping
from types to types', hoping that this would carry enough context-setting
information to make it more accessible.

[Lasse Reichstein Nielsen, 2017/07/12 12:08:06]

Let's not write something that can only be understood by "a bunch of people". :)

People who understand meta-functions, there are dozens of us!

+which may be used, say, as a type annotation. We use the phrase
+*parameterized typedef* to refer to the latter. Dart has had support for
+parameterized typedefs for a while, and the new syntax supports
+parameterized typedefs as well. Here is an example of a parameterized
+typedef, and a usage thereof:
+
+```dart
+typedef I<T> = List<T> Function(T); // New form.
+typedef List<T> J<T>(T t); // Old form.
+I<int> myFunction(J<int> f) => f;
+```
+
+Here, we have declared two equivalent parameterized typedefs `I` and `J`,

[Lasse Reichstein Nielsen, 2017/07/11 11:13:53]

Here -> In this example
(just for explicitness)

[eernst, 2017/07/11 15:50:05]

Done.

+and we have used an instantiation of each of them in the type annotations
+on `myFunction`. Note that the type of `myFunction` does not include *any*
+generic types, it is just a function that accepts an argument and returns a
+result, both of which have a non-generic function type that we have
+obtained by instantiating a parameterized typedef. The argument type might
+as well have been declared using the traditional function signature syntax,
+and the return type (and the argument type, by the way) might as well have
+been declared using a regular, non-parameterized typedef:
+
+```dart
+typedef List<int> K(int i); // Old form, non-generic.
+K myFunction2(List<int> f(int i)) => f; // Same as myFunction.
+```
+
+The new syntax allows for using the two kinds of type parameters together:
+
+```dart
+typedef L<T> = List<T> Function<S>(S, {T Function(int, S) factory});
+```
+
+This declares `L` to be a parameterized typedef; when instantiating `L`
+with an actual type argument as in `L<String>`, it becomes the type of a
+generic function that accepts a type argument `S` and two value arguments:
+one required positional argument of type `S`, and one named optional
+argument with name `factory` and type `String Function(int, S)`; finally,
+it returns a value of type `List<String>`.
+
+## Syntax
+
+The new form of `typedef` declaration uses the following syntax (there are
+no deletions from the grammar; addition of a new rule or a new alternative
+in a rule is marked with NEW and modified rules are marked CHANGED):
+
+```
+typeAlias:
+  metadata 'typedef' typeAliasBody |
+  metadata 'typedef' identifier typeParameters? '=' functionType ';' // NEW
+functionType: // NEW
+  returnType? 'Function' typeParameters? parameterTypeList
+parameterTypeList: // NEW
+  '(' ')' |
+  '(' normalParameterTypes ','? ')' |
+  '(' normalParameterTypes ',' optionalParameterTypes ')' |
+  '(' optionalParameterTypes ')'
+normalParameterTypes: // NEW
+  normalParameterType (',' normalParameterType)*
+normalParameterType: // NEW
+  type | typedIdentifier
+optionalParameterTypes: // NEW
+  optionalPositionalParameterTypes | namedParameterTypes
+optionalPositionalParameterTypes: // NEW
+  '[' normalParameterTypes ','? ']'
+namedParameterTypes: // NEW
+  '{' typedIdentifier (',' typedIdentifier)* ','? '}'
+typedIdentifier: // NEW
+  type identifier
+type: // CHANGED
+  typeWithoutFunction |
+  functionType
+typeWithoutFunction: // NEW

[Lasse Reichstein Nielsen, 2017/07/11 11:13:52]

A positive description is usually easier to work with than a negative
description. Being "without function" doesn't say what it really is.
That said, I can't find a good word to cover it (because it may contain function
types anyway, just not the function-type syntax).

[eernst, 2017/07/11 15:50:05]

Right, it is "any type which is not syntactically a function type". The name of
this non-terminal was modeled on several existing non-terminals named
'..WithoutCascade'. No changes applied for now.

+  typeName typeArguments?
+typeWithoutFunctionList: // NEW
+  typeWithoutFunction (',' typeWithoutFunction)*
+mixins: // CHANGED
+  'with' typeWithoutFunctionList
+interfaces: // CHANGED
+  'implements' typeWithoutFunctionList
+superclass: // CHANGED
+  'extends' typeWithoutFunction
+mixinApplication: // CHANGED
+  typeWithoutFunction mixins interfaces?
+newExpression: // CHANGED
+  'new' typeWithoutFunction ('.' identifier)? arguments
+constObjectExpression: // CHANGED
+  'const' typeWithoutFunction ('.' identifier)? arguments
+redirectingFactoryConstructorSignature: // CHANGED
+  'const'? 'factory' identifier ('.' identifier)?
+  formalParameterList '=' typeWithoutFunction ('.' identifier)?
+```
+
+The syntax relies on treating `Function` as a fixed element in a function
+type, similar to a keyword or a symbol (many languages use symbols like
+`->` to mark function types).
+
+*The rationale for using this form is that it makes a function type very
+similar to the header in a declaration of a function with that type: Just
+replace `Function` by the name of the function, and add missing parameter
+names and default values.*
+
+*The syntax differs from the existing function type syntax
+(`functionSignature`) in that the existing syntax allows the type of a
+parameter to be omitted, but the new syntax allows parameter names to be
+omitted. The rationale for this change is that a function type where a
+parameter has a specified name and no type is very likely to be a
+mistake. For instance, `int Function(int)` should not be the type of a
+function that accepts an argument named "int" of type `dynamic`, it should
+specify `int` as the parameter type and allow the name to be
+unspecified. It is still possible to opt in and specify the parameter name,
+which may be useful as documentation, e.g., if several arguments have the
+same type.*
+
+The modification of the rule for the nonterminal `type` may cause parsing
+ambiguities. We intend to handle them by the following disambiguation rule

[Lasse Reichstein Nielsen, 2017/07/11 11:13:53]

intend to handle -> handle

This is a specification (even if it's an informal one) so its text is normative.
Readers can't use "intend" for anything, they need to know what to do or not do.

IOW: Do, or do not, there is no "intend".

[eernst, 2017/07/11 15:50:04]

Right, `intend` must go.

But I think the main issue here is that we just decided to drop the heuristic in
the generic method syntax document, going for the idealistic "disambiguation
favors a generic invocation" and ignoring the consequences of that approach for
the complexity of parsing.

So maybe we should simply say that in case of ambiguity we favor a parse that
makes `Function` part of a function type? This would be an extension of the
current rule, because "commit to parsing a function type upon having seen .."
cannot ever do anything other than forcing exactly the same disambiguation in
some cases (and possibly not all of them).

I have no idea how difficult it would be to satisfy that specification in a
parser, though.

Right now I've kept the heuristic and just deleted the `intend` part.

[Lasse Reichstein Nielsen, 2017/07/12 12:08:06]

As discussed offline, there is a difference between this syntax and the generic
function call syntax — mainly that this syntax is very local so the user can
easily determine whether the rule applies or not, where the generic function
syntax requires reasoning about far-away matching braces too.

+in the parser: If the parser is at a location L where the tokens starting
+at L may be a `type` or some other construct (e.g., in the body of a
+method, when parsing something that may be a statement and may also be a
+declaration), the parser can commit to parsing a type by detecting that it
+is looking at the identifier `Function` followed by `<` or `(`, or that it
+is looking at a type followed by the identifier `Function` followed by `<`
+or `(`.
+
+*Note that this disambiguation rule does require parsers to have unlimited
+lookahead. However, if a "diet parsing" strategy is used where the token

[Lasse Reichstein Nielsen, 2017/07/11 11:13:53]

Drop "diet parsing", just say "parsing strategy".
"Diet parsing" is not a general term, and where we use it, it doesn't mean just
the brace-matching. It's more precisely described as parsing method signatures
without parsing the bodies, but how that's done isn't defined.

[eernst, 2017/07/11 15:50:04]

Done.

+stream already contains references from each opening bracket (such as `<`
+or `(`) to the corresponding closing bracket then the decision can be
+taken in a fixed number of steps: If the current token is `Function` then
+check the immediate successor (`<` or `(` means yes, we are looking at
+a `type`, everything else means no) and we're done; if the first token is
+an `identifier` other than `Function` then we can check whether it is a
+`qualified` by looking at no more than the two next tokens, and we may then
+check whether the next token again is `<`; if it is not then we look for
+`Function` and the token after that, and if it is `<` then look for the
+corresponding `>` (we have now skipped a generic class type), and then
+the successor to that token again must be `Function`, and we finally check
+its successor (looking for `<` or `(` again). This skips over the
+presumed type arguments to a generic class type without checking that they
+are actually type arguments, but we conjecture that there are no
+syntactically correct alternatives (for example, we conjecture that there
+is no syntactically correct statement, not a declaration, starting with
+`SomeIdentifier<...> Function(...` where the angle brackets are balanced).*

[Lasse Reichstein Nielsen, 2017/07/11 11:13:52]

It's not clear to me where we allow parsing Function( as a function type.
Is it only where a type may occur, or everywhere?
How do we know where a type may occur?
- start of declaration (type annotation)
- start of parameter (type annotation)
- after is/as/on
- as type argument
Is that it?

This still sounds wishy-washy to me.
Are you defining or describing things here? (Is it nominative or descriptive?)
Are you just giving hints to parsers?

How about just:
- The grammar is changed as above.
- The new grammar is ambiguous. Example: (pick a good example)
- In any case where `Function(` and `Function<` occurs where it could be the
prefix of a functionType production, it must parsed as a type.
- This disambiguates all ambiguities introduced by the new grammar.

[eernst, 2017/07/11 15:50:05]

The words `the tokens starting at L may be a \`type\` or some other construct`
are intended to specify that this rule only applies when the current location
can be a `type` (that is, there exists a suffix to the input that we have
already read such that the complete input is syntactically correct and the
construct starting at L is a `type`).
We're not interested in all locations where a type may occur, only the locations
where it may occur, and something else may also occur. (With the idealistic
approach where we just say what's "favored" in case of an ambiguity, we will
need to know whether the input can be such that >1 parse tree is possible; with
a heuristic we will actually allow the parser to make a commitment to parsing a
`type`, even though there may be cases where that leads to a parse error and a
different choice would lead to a successful parse).

So---when may we have a type and something else?

Ideally, we consider all possible libraries (i.e., complete inputs) which begin
with the input that we have already read, and which are syntactically correct
Dart libraries. Then we consider all parse
trees admitted by the grammar for those inputs. If there exists one such parse
tree where the leaf at location L is the left-most leaf of a subtree of the
parse tree whose root is `type`, then "a `type` may occur at L".

In practice, if we use a recursive descent parser (as we do) and it is complete
(so, if there is a parse tree on a given input, the parser will find that parse
tree: presumably we do have that property) then the parser will need to make a
choice between parsing a `type` and parsing something else at L, which means
that it will call either `parseType`, `parseX1`, .., or `parseXn`, for some
other non-terminals or terminals X1..Xn. So in this case we know that we will
_only_ need to use this disambiguation rule in a situation where we need to make
such a choice.

Isn't that reasonably well-understood?
Sounds plausible, but even without a complete list I think it's well-defined.
It is a specification of a disambiguation heuristic that parsers may use. Hence,
it is a limit on the set of syntactically correct Dart libraries: If a library
gives rise to a parsing failure with a Dart parser which uses this heuristic, it
is a problem with the library, not a bug in the parser.

We may even say that parsers _must_ use this heuristic, such that all libraries
which _might_ incur this parsing failure _will_ indeed have this parsing
failure.
OK, that was exactly what I suggested a few comments ago, based on a similar
change in the other document of this CL. The problem is that we may not be able
to implement that (without excessive performance hits).

... WDYT? ...

[Lasse Reichstein Nielsen, 2017/07/12 12:08:06]

That's actually not what I'm saying - this does use only the prefix to determine
whether to commit to the `Function(` or `Function<` being function-type syntax
or an identifier followed by another token. It does not use later tokens to make
the determination, which means that later tokens can be invalid for the chosen
parsing, even if it would be valid for another parsing of the same input.

[eernst, 2017/07/12 13:15:38]

As discussed IRL, there is no finite bound on the `type` part which may occur
before `Function`, and we do not have a simple rule which will eliminate the
need to parse the `type` in total before we encounter `Function`, `(`/'<` and
make a decision.

But I think we agreed that it is not a problem, in practice those `type`
expressions are not going to be large, and the problem does not lend itself to
exponential blowup.

[Lasse Reichstein Nielsen, 2017/07/13 06:57:17]

Agree. 
It's worth recognizing that 
  SomeIdentifier<...>
appears where a type is possible, so it's not inside a place that allows
top-level comma-separated expressions.
I.e., SomeIdentifier<foo, bar> must be a type, and SomeIdentifier<foo> must be a
type. Basically, we can commit SomeIdentifier< to being a type at the first ","
or ">", before even reaching Function, which means that *if* there is a matching
">" for the "SomeIdentifier<", then it is a type, not a comparison (if there is
no comma, it's not a valid expression, if there is a comma, it's not separating
expressions, so the <...> must be a type argument).

+
+*Note that this disambiguation rule will prevent parsing some otherwise
+correct programs. For instance, the declaration of an asynchronous function
+named `Function` with an omitted return type (meaning `dynamic`) and an
+argument named `int` of type `dynamic` using `Function(int) async {}` will
+be a parse error, because the parser will commit to parsing a type after
+having seen "`Function(`" as a lookahead. However, we do not expect that it
+will be a serious problem for developers to be unable to write such
+programs.*
+
+## Scoping
+
+Consider a typedef declaration as introduced by this feature, i.e., a
+construct on the form
+
+```
+metadata 'typedef' identifier typeParameters? '=' functionType ';'
+```
+
+This declaration introduces `identifier` into the enclosing library scope.
+
+Consider a parameterized typedef, i.e., a construct on the form
+
+```
+metadata 'typedef' identifier typeParameters '=' functionType ';'
+```
+
+Note that in this case the `typeParameters` are present, not optional. This

[Lasse Reichstein Nielsen, 2017/07/11 11:13:52]

Drop the "not optional". Here you are giving a concrete example (even if it's
still abstract), not a pattern. Optionality only applies in patterns, so you are
comparing a concrete example with a pattern, which is a difference in kind, and
why I started out reading this as a pattern as well.

[eernst, 2017/07/11 15:50:04]

Dropped `optional`, that's clearly better.

By the way, this _is_ a pattern. It allows for the construction of a subset of
the strings derivable from the non-terminal `typeAlias` (and it is not equal to
the set of strings derivable from any existing non-terminal, so I couldn't just
use such a non-terminal). The following text is applicable to all of those
derivatives, so it does matter that it's not just an example.

+construct introduces a scope known as the *typedef scope*. Each typedef
+scope is nested inside the library scope of the enclosing library. Every
+formal type parameter declared by the `typeParameters` in this construct
+introduces a type variable into its enclosing typedef scope. The typedef
+scope is the current scope for the `typeParameters` themselves, and for the
+`functionType`.

[Lasse Reichstein Nielsen, 2017/07/11 11:13:52]

I'm not sure it's worth it to avoid adding a typedef scope to typedefs without
type parameters, it'll just be empty anyway and make no difference.

[eernst, 2017/07/11 15:50:04]

Right. It'll be a small change. I'm not doing it now, let's decide on that
tomorrow IRL.

+
+Consider a `functionType` specifying a generic function type, i.e., a
+construct on the form
+
+```
+returnType? 'Function' typeParameters parameterTypeList
+```
+
+Note again that `typeParameters` are present, not optional. This construct
+introduces a scope known as a *function type scope*. The function type
+scope is nested inside the current scope for the associated `functionType`.
+Every formal type parameter declared by the `typeParameters` introduces a
+type variable into its enclosing function type scope. The function type
+scope is the current scope for the entire `functionType`.
+
+*This implies that parameterized typedefs and function types are capable of
+specifying F-bounded type parameters, because the type parameters are in
+scope in the type parameter list itself.*
+
+## Static Analysis
+
+Consider a typedef declaration as introduced by this feature, i.e., a
+construct on the form
+
+```
+metadata 'typedef' identifier typeParameters? '=' functionType ';'
+```
+
+It is a compile-time error if a name *N* introduced into a library scope by
+a typedef has an associated `functionType` which depends directly or

[Lasse Reichstein Nielsen, 2017/07/11 11:13:52]

Define "depends".
I guess it's actually pretty hard, it really means that the transitive closure
of type declarations used by N must not refer to N.

How about:

class C implements List<N> {}
class D extends C;
typedef N = D Function(D);

I'd say that it "depends on" N.
How about:

class C {
  N foo(N x) => x;
}
class D extends C;
typedef N = D Function(D);

Does that depend on N? Probably not, because the nominative type C is
independent of N.

(So, this is an unclear definition, but probably no more unclear than other
similar dependency requirements we already have in the language).

[eernst, 2017/07/11 15:50:04]

This is concerned with static analysis, and dependencies can only arise when a
compile-time lookup operation resolves a given name application N1 to a specific
declaration D1, which in turn establishes a dependency edge from N1 to D1; edges
coming from the body of a declaration D2 are considered to be edges from D2 to
other declarations.

Now, it is a compile-time error if a typedef declaration D is such that the
static dependency graph has a cycle whose nodes are all typedefs.
Can't do that. But ok. ;-)
With the 'all typedefs' clause that would be allowed. Consider this variant:

  class C implements List<D Function(D)> {}
  class D extends C {}

This is obviously "the same thing", but there is nothing stopping us from having
such a setup. So I wouldn't expect problems caused by allowing the declarations
that include `typedef N` (i.e., your example).

A main point would be that we don't want to go beyond type aliases, so in
particular a `typedef` cannot be allowed to be recursive. This would be
prevented in a very direct manner by requiring that there are no dependency
cycles _of_typedefs_, and I suspect that other cycles are benign. Can you think
of any exceptions?
Same situation, same response: No problem.
That's possible, but it shouldn't be hard to specify the "cycle of typedefs"
requirement.

+indirectly on *N*. It is a compile-time error if a bound on a formal type
+parameter in `typeParameters` is not a type. It is a compile-time error if
+a typedef has an associated `functionType` which is not a type when
+analyzed under the assumption that every identifier resolving to a formal
+type parameter in `typeParameters` is a type. It is a compile-time error if
+an instantiation *F<T1..Tk>* of a parameterized typedef is mal-bounded.

[Lasse Reichstein Nielsen, 2017/07/11 11:13:53]

Is it? 
We allow super-bounded generic types in some cases now, so should we allow
super-bounded function types (or does that not make sense)?

[eernst, 2017/07/11 15:50:05]

Aha?! I supported super-bounded types and still do, so that sounds good, but I
had no idea that they had been introduced. When was that?

Anyway, we could also decide that parameterized typedefs don't have bounds at
all, the constraints on type arguments are derived from the body (so an
instantiation *F<T1..Tk>* is malbounded if and only if the resulting body from
that instantiation contains a malbounded type). That would be "ugly" in the
sense that the typedef as such is de-emphasized as an abstraction (it leaks),
but on the other hand it would take away the requirement to tease out some
working bounds which may in some cases be an intersection type which can't be
specified).

Another difficulty is that we may have cases where we need a lower bound (when
function types have contravariant argument types, i.e., in strong mode):

  typedef F<X> = void Function(X);
  class C<Y extends F<num>> {}
  typedef G<X super num> = C<F<X>> Function();

.. except that we can't say "X super num".

It's not obvious to me how we can handle bounds on parameterized typedefs in a
good way.

[Lasse Reichstein Nielsen, 2017/07/12 12:08:06]

Agree that it is a problem, and as discussed it doesn't stop at super-bounds. We
can probably cause multiple constraints on a type variable that would require
any or all of union, intersection and super-bounded types to express.

We need to figure out whether the `G` declaration above is allowed without the
"super num", and if so, when any actual error is reported.

[eernst, 2017/07/12 13:15:37]

I'd suggest that we use the current behavior of `dartanalyzer --strong`, which
is to require that the typedef has declared bounds which force the body to be
well-bounded. The example `G` will then be impossible to compile, but the
`typedef` construct as such will be a more well-rounded abstraction.

To make this happen, I adjusted the wording to say `well-bounded`, about the
body.

+
+*This implies that a typedef cannot be recursive. It can only introduce a
+name as an alias for a type which is already expressible as a
+`functionType`, or a name for a type-level function F where every
+well-bounded invocation `F<T1..Tk>` denotes a type which could be expressed
+as a `functionType`. Following
+[common terminology](https://en.wikipedia.org/wiki/Kind_(type_theory)), we
+could say that a typedef can define entities of kind ` * ` and of kind
+` * -> * `, and, when it is assumed that every formal type parameter of the
+typedef (if any) has kind ` * `, it is an error if the right hand side of the
+declaration denotes an entity of any other kind than ` * `; in particular,
+declarations of entities of kind ` * -> * ` cannot be curried.*

[Lasse Reichstein Nielsen, 2017/07/11 11:13:53]

Is this important? Does it affect implementation, or is it just commentary?
(That is: I got lost reading this, and I didn't follow the link. Expect other
readers to do the same. If this is important for implementation in any way, it
needs to be rephrased to be actionable.)

[eernst, 2017/07/11 15:50:05]

It is intended to be helpful for people who know "kind systems" from languages
like Haskell or Scala or from theoretical calculi.

I've changed the wording to make it more obvious that this particular sentence
is intended for those readers who already know kind systems. Since the whole
paragraph is marked as rationale (*..*) it is already indicated that it is
optional reading.

+
+It is a compile-time error if a name declared in a typedef, with or without
+actual type arguments, is used as a superclass, superinterface, or mixin. It
+is a compile-time error if a generic function type is used as a bound for a
+formal type parameter of a class or a function. It is a compile-time error if
+a generic function type is used as an actual type argument.
+
+*Generic function types can thus only be used in the following situations:*
+
+- *as a type annotation on an local, instance, static, or global variable.*
+- *as a function return or parameter type.*
+- *in a type test.*
+- *in a type cast.*
+- *in an on-catch clause.*
+- *as a parameter or return type in a function type.*
+
+*The motivation for having this constraint is that it ensures that the Dart type
+system admits only predicative types. It does admit non-prenex types, e.g.,
+`int Function(T function<T>(T) f)`. From research into functional calculi
+it is well-known that impredicative types give rise to undecidable subtyping,
+e.g.,
+[(Pierce, 1993)](http://www2.tcs.ifi.lmu.de/lehre/SS07/Typen/pierce93bounded.pdf),
+and even though the Dart type system is very different from F-sub, we cannot
+assume that these difficulties are absent.*
+
+## Dynamic Semantics
+
+The addition of this feature does not change the dynamic semantics of
+Dart.
+
+## Changes
+
+2017-May-31: Added constraint on usage of generic function types: They
+cannot be used as type parameter bounds nor as type arguments.
+
+2017-Jan-04: Adjusted the grammar to require named parameter types to have
+a type (previously, the type was optional).
+
+2016-Dec-21: Changed the grammar to prevent the new function type syntax
+in several locations (for instance, as a super class or as a mixin). The
+main change in the grammar is the introduction of `typeWithoutFunction`.
+
+2016-Dec-15: Changed the grammar to prevent the old style function types
+(derived from `functionSignature` in the grammar) from occurring inside
+the new style (`functionType`).