Add feature specification for inline classes

[eernstg]

This PR adds a feature specification of 'inline classes', which was obtained by taking the current version of the feature specification of 'views' and rename the construct from 'view class' to 'inline class'. It also removes the support for primary constructors (such that we get more time to get that feature just right and introduce it in general, not just for inline classes).

Finally, this PR adjusts the text accordingly. In particular, it changes the word 'superview' to 'superinterface', and it specifies that it is a compile-time error for an inline class to have a type T in the implements clause unless T is an inline class.

The rules about name clashes among "inherited" names are unchanged: It is a compile-time error if an inline class V has superinterfaces V1 and V2, and both of them has a member named m, and it is not the same declaration (e.g., in a diamond superinterface structure). The error is eliminated by adding a declaration named m to V.

[eernstg]

Review response.

[eernstg]

Has been clarified now. late is an error, no matter what's in the rest of the instance variable declaration. Also, it's an error if there is no final. So late int v = 42; has two errors.

It is allowed for the instance variable to have an initializing expression, but it's hardly useful.

[eernstg]

Thanks for a lot of useful input! I believe the main remaining issue is the syntax super.V2.foo(), used to specify a "superinvocation" of foo in the superinterface (and inline class) V2. This would be needed, in particular, when writing a forwarding member in order to resolve a name clash:

inline class V1 { void foo() {}}
inline class V2 { void foo() {}}
inline class V3 implements V1, V2 { void foo() => super.V2.foo(); }

If we drop that syntax (and do not replace it by something else), I think the only easily expressible way to do the same thing is a cast. Any cast is unsafe, and it is harder to understand the purpose and effect of the code with the cast.

inline class V3 implements V1, V2 { void foo() => (this as V2).foo(); }}

[leafpetersen]

If we drop that syntax (and do not replace it by something else), I think the only easily expressible way to do the same thing is a cast. Any cast is unsafe, and it is harder to understand the purpose and effect of the code with the cast.

I don't really think this is true. Assigning it to a variable of the super-interface type before calling the method works fine and is perfectly safe.

[eernstg]

@leafpetersen wrote:

Assigning it to a variable of the super-interface type before calling the method works fine and is perfectly safe.

Right, I was just considering expression forms (because it enables =>, which is probably considered desirable).

[eernstg]

A couple of extra comments came up. In particular, the ability to do inline-erasure (computing a non-inline type that corresponds to any given inline type, by going repeatedly to the representation type) is finicky, and may need more scrutiny.

Another thing is the fact that the representation object may be null if the representation type is potentially nullable, but this doesn't mean that we can't call the inline class methods. So should the inline type be considered potentially nullable?

[eernstg]

Removed the I.super.foo syntax, adjusted other locations based on comments. PTAL.