Analyzer's printing of function types will need to change to support nullability

[stereotype441]

The Dart syntax for function types takes the form returnType Function(parameters), but the analyzer reports function types (e.g. in diagnostic messages) using the terser syntax (parameters) → returnType. With the introduction of non-nullability, this will leads to an ambiguity: does (parameters) → returnType? mean that the return type is nullable, or that the entire function is nullable?

We should either adapt the display of function types to disambiguate with parentheses, or switch to using Function syntax.

[bwilkerson]

At the time that we chose that syntax, generic function types didn't exist. But now that it does, I think it would be better to switch to using the generic function syntax because I think it will be more familiar looking to more users.

[lrhn]

I think we should use Function syntax for function types everywhere.
Even function.runtimeType.toString().

[stereotype441]

At the time that we chose that syntax, generic function types didn't exist. But now that it does, I think it would be better to switch to using the generic function syntax because I think it will be more familiar looking to more users.

Agreed! I plan to do some investigation to see if the change would be breaking. (Technically it shouldn't be, because clients shouldn't rely on the behavior of FunctionType.toString(), but I wouldn't be surprised if some clients rely on it in unit tests.)

[stereotype441]

Note that when we do this work we should eliminate the code duplication between FunctionTypeImpl.appendTo and _ElementWriter.writeType.