Extension types feature specification

[eernstg]

This PR is a proposal for how we could specify extension types, following up on the discussions it the language team this week.

cc @dart-lang/language-team

[eernstg]

It includes the special case of the primary constructor syntax, and it makes this syntax required (it's a syntax error to not have it). It allows non-extension-type superinterfaces as long as they are supertypes of the representation type.

As a thought experiment (which we could take seriously), it does not make the representation name available as a getter. This means that the representation object is treated, as we've mentioned in various discussions, as a name which is in scope in the extension type body but not accessible from anywhere else (just like type parameters).

[bwilkerson]

FWIW, I think this proposal would be much less confusing to users than the inline classes proposal. In particular I think the semantics of both redeclaration and fields are far less surprising.

[eernstg]

Just landed a commit that drops the special exception whereby e.id is an error when id is the representation name and e isn't this. In other words, we're dropping the lexical-scope-only rule, the representation declaration works just like any other getter now. If the developer wishes to prevent direct access (at least from other libraries), the representation name should be private.

[lrhn]

Got to line 915.

[mit-mit]

Can we start with a motivating example, similar to https://github.com/dart-lang/language/blob/main/accepted/future-releases/inline-classes/feature-specification.md#motivation ?

[lrhn]

(I'm slighlty split here. Motivating examples are nice for getting things accepted, but once accepted, I'd like a tight, sharp specification the of what the feature does, without motivation or discussions about alternatives. Just the facts.

Could we split it in two files? Motivation/discussion and specification. If the specification doesn't work without the other text, then it's already non self-contained enough.

[eernstg]

Great feedback, @lrhn! Changed a bunch of things and uploaded.
Didn't do anything about the introductory example, yet.

[eernstg]

Further revisions have been made now. In particular, a lot of things became simpler by introducing the notion of 'an extension type member' and 'a non-extension type member' maintains the distinction that the declaration of the given member is located in an extension type declaration respectively it is in the interface of a non-extension type superinterface.

So we don't need to re-explain that we need to look up through the superinterface graph in order to see whether any given member came from an extension type or from a non-extension type.

[eernstg]

Just updated the grammar to support const on the primary constructor, and the rules to say that the constructor is constant if and only if const is present in the declaration header.