Write specification for generic function type syntax

[floitschG]

This is the spec issue for #27527.

• 1.50
• 2.0

[eernstg]

I started writing an informal specification following the style we have used for generic method syntax, initializing formal access, etc. Shared on Google Drive. Will be public when it has matured a bit.

[dgrove]

@eernstg can you please provide an update on the spec?

[eernstg]

I believe the spec is usable for implementation at this point. It was adjusted yesterday such that it describes a generally available T Function<...>(...) syntax (as opposed to the previous version of the grammar where that syntax could only be used in one particular location). I think we can make the spec available to the public when we have enough of an implementation to be able to declare with reasonable certainty that there are no surprises, e.g., when it comes to parsing conflicts.

[munificent]

Can we close this bug then?

[eernstg]

The spec is usable for implementation, but not finished. In particular, the static analysis part (which is unfinished) prevents the new typedefs from being recursive, and similar things that I've been looking into today and will continue to work on tomorrow, but this won't stop anyone from implementing the parsing part.

[munificent]

Oh, wait. You're referring to the "informal specification", right?

This issue is about the actual real final language specification (i.e. the .tex file) changes. For the informal spec, it just needs to be made public and linked to from the metabug.

[eernstg]

OK, but we haven't changed the language specification file at all on this topic. I've been referring to the informal spec everywhere in this issue.

We need to have two sub-issues to distinguish explicitly between the informal spec ("when we know what to do") and the formal spec (which is less time critical, because the tool teams can implement based on the informal spec, and we even want that because their feedback may cause some adjustments).

[mit-mit]

Let's keep this bug for the real language spec, I have linked the informal spec from the meta issue.

[munificent]

We need to have two sub-issues to distinguish explicitly between the informal spec ("when we know what to do")

So far, we haven't filed tracking issues for that task. I think the assumption is that the language team won't open a metabug or expect people to start working on any of the subtasks until we've given them a written proposal (or "informal spec" or however you want to call it).

[mit-mit]

@floitschG did we ever complete the spec for this?

[eernstg]

There is no formal spec yet. The informal spec is here.

[eernstg]

With respect to the bullet point '2.0', this issue is blocked until work on a specification of Dart 2 is initiated.

[eernstg]

Work is ongoing: This CL adds a Dart 2 specification of generic functions to 'dartLangSpec.tex' (except that error is still spelled 'warning', and subtype rules are left untouched in their Dart 1.x form). That effort addresses #27529 and subsumes this issue (because the generic method syntax is the same for Dart 1.x and for Dart 2), hence closing this one.