Specification needs to be updated for non-strong mode generic methods.

[leafpetersen]

Informal specification here:

https://docs.google.com/document/d/1nccOSkdSyB9ls7TD8gUqIu6Wl2J_9bTSOoMCEIoAiQI/edit#heading=h.dnanv15dn1me

[leafpetersen]

Assigning @eernstg for now - if you won't be the person doing this, can you sort out who will?

[leafpetersen]

@bwilkerson noticed that the informal spec has some discussion of super constraints on type parameters, which I don't think we intend to support (at least not yet). @eernstg, can you clarify that in the doc?

[eernstg]

Let's use 'syntax-only generic methods' to refer to the semantics specified in Feature: Generic Method Syntax.

Then we have two topics here: (1) Should we update the language specification to cover syntax-only generic methods?, and (2) what's the status of super bounds?

For (1), I didn't expect to change the language specification to cover syntax-only generic methods, because that is a temporary approach which should be extended to support full-fledged generic methods (which would of course be covered in detail in the language specification). So we would rely on the informal document Feature: Generic Method Syntax for the specification of syntax-only generic methods. The full-fledged specification includes local type inference of actual type arguments passed to invocations of generic functions, and the work on specifying local type inference is not complete (and we can't just whip up a brief clarification, it will take some time).

For (2), I also don't think we've decided that we will have super bounds on type arguments; I adjusted Feature: Generic Method Syntax to say explicitly that an implementation does not need to support them.

That said, I think they are useful and probably not hard to implement. In our discussions a long time ago Lasse mentioned that List could use the signature S firstWhere<S super T>(bool test(T element), S defaultValue()), and I believe we had other cases as well. But it is of course an enhancement which can be added later, without breaking existing programs.

[leafpetersen]

I think that for now we should treat the syntax-only generic methods as an experiment and focus on specifying the strong mode behavior.

I think that 'super' bounds would be a useful extension, but I'd rather not tackle them now. I think there are some non-trivial implications to work through for inference and for subtyping.

[eernstg]

The informal specification has been adjusted, and the resulting document is available here: Feature: Generic Method Syntax.

[leafpetersen]

Are we planning to incorporate this into the formal spec?

[eernstg]

I'm doing that now.

[eernstg]

CL for that change.

[mit-mit]

@eernstg is this done?

[lrhn]

CL (https://codereview.chromium.org/2690553002/) still not landed.

[eernstg]

That CL was stalled for a while, because a new (reifying) semantics was being discussed, specified informally, and implemented in the vm. Turns out that dart2js will not implement the same thing (now, at least), so we will indeed stick to the non-reifying semantics for Dart 1.x. Now working on landing that CL again.

[eernstg]

Closing: Updating the language specification to specify anything new pertaining to Dart 1.x is now an obsolete task.