What declaration syntax should structs and extension structs use?

[leafpetersen]

The proposal for structs and extension structs here uses the declaration forms:

  struct Foo(int x, int y) { 
    // members here
  }
  extension struct Bar(int x) { 
   // members here
  }

The idea of re-using the basic class syntax is fairly core to the proposal (though we could certainly incorporate pieces of this proposal into other proposals), but the choice of keywords is fairly arbitrary. The proposal lists a number of alternatives, largely around either choosing a new keyword (e.g. view, or record), or around using a modified on class (e.g. data class and view class).

This issue is for discussion of main declaration syntax. Discussion of other syntactic choices (e.g. the primary constructor syntax) should be done in a separate issue.

[leafpetersen]

cc @mit-mit @lrhn @eernstg @chloestefantsova @johnniwinther @munificent @stereotype441 @natebosch @jakemac53 @rakudrama @srujzs @sigmundch @rileyporter @mraleph

[leafpetersen]

I'll admit that the data class and view class variant of the syntax is growing on me.

[lrhn]

I'm slightly worried about the "view class"/"extension struct" syntax looking too much like class syntax, even though it really isn't a class. The implements InterfaceName syntax is particularly worrisome, because it suggests a connection between the view and the interface, even though there is none.
The value might be assignable to the interface type, and it might forward interface methods to the underlying object, but there is no relation between the members declared in the extension struct/view and the interface.

Also, if it is really about assignability, we may want to allow non-interface types in the implements clause, which is extra confusing. (Like extension struct Foo(void Function(int)) implements void Function(int) { ... } for the call method?)

I think I prefer the view Foo on TargetType, because the on makes it clear that it's not an interface relationship, it's just a type requirement. With show clauses, the view proposal can still expose the members of the underlying object, but not in a way which suggests that the new view type actually implements the interface.

[mraleph]

I think we should avoid struct because this keyword is rather overloaded and means different things in other languages (e.g. C# and C++ has mutable structs), it also clashes with things like ffi.Struct we already have in our core libraries. Maybe record would work better if we are looking for a single keyword.

For struct specifically I would prefer value class or data class. value clearly signals that we forgo an identity and are likely to treat an instance of this class as a value (rather than working with it through a reference). view is also somewhat an overloaded term (e.g. UI views come to mind).

[mit-mit]

facade class is another option for view

[leafpetersen]

@lrhn

The value might be assignable to the interface type, and it might forward interface methods to the underlying object, but there is no relation between the members declared in the extension struct/view and the interface.

I don't understand what you are saying here. In this proposal I believe there is exactly the same relation between members declared in an extension struct and the interface as there are between members declared in a class and an interface that it implements. I don't understand what relation you see the latter that is missing in the former.

Also, if it is really about assignability, we may want to allow non-interface types in the implements clause, which is extra confusing. (Like extension struct Foo(void Function(int)) implements void Function(int) { ... } for the call method?)

I don't see an argument for doing this, and I don't propose to do this. Can you expand on why you see it as something we should do?

I think I prefer the view Foo on TargetType, because the on makes it clear that it's not an interface relationship, it's just a type requirement.

I don't know what you mean by a type requirement here, can you expand?

With show clauses, the view proposal can still expose the members of the underlying object, but not in a way which suggests that the new view type actually implements the interface.

That syntax is reasonable, but to be clear it provides different affordances. In this proposal the new view type does actually implement the interface. In the view proposal, the new view type cannot implement an interface.

[eernstg]

In the view proposal, the new view type cannot implement an interface.

Indeed, there is no subtype relationship, we only check that every member is implemented with a correct override.

But when the view has an implements clause, the corresponding boxing class has the same implements clause, with completely normal semantics. So we just need to take one step to get the ability to be a subtype (of any non-sealed type that the author of the view has chosen to implement, they don't have to be supertypes of the type of the underlying representation).

Also note that the boxed object preserves the implementation of all methods declared in the view, so myView.box.foo() will run the code in the view if foo is declared in the view, but (myExtensionStruct as ImplementedType).foo() will run the code in the class of the underlying representation, whether or not there is an implementation of foo in the extension struct (of course, it may be an error to implement foo in the extension struct, cf. #2370).

[leafpetersen]

But when the view has an implements clause, the corresponding boxing class has the same implements clause, with completely normal semantics.

Yes, I was being brief.

In this proposal, if an extension struct S has an implements Foo, then:

• The type S is a subtype of Foo (with all the usual compositionality, including that List<S> is a subtype of List<Foo>
• The members of S are a superset of the members of Foo
• If we disallow overrides, then dynamic dispatch and subsumption will not change the dispatch semantics, but if we allow overrides, dynamic dispatch and subsumption will cause a change in dispatch

In the view proposal, if a view V has an implements Foo, then:

• The type V is not a subtype of Foo, but the type V.class (or whatever it is called) is.
• The members of V are a superset of the members of Foo
• dynamic dispatch causes a change in dispatch, and subsumption doesn't apply (I think), but the object produced by V.box will always dispatch to the locally defined methods.

My primary concerns on this front with the view proposal are as follows:

• I think that it is surprising to users to see implements Foo on a declaration of S, and not have S be a subtype of Foo
• The .box affordance pushes the complexity onto the end users. API designers cannot hide the complexity from end users, except by not relying on .box. If .box is part of the design of their API, then end consumers must understand and manually follow the required protocol. This pushes cognitive load onto consumers of APIs.

[eernstg]

We could actually start with a zero-cost abstraction proposal (view / extension struct, whatever) where there is no support for implements, and no subtype relationship between the zero-cost abstraction and any other types than top and bottom, or type equivalence (mutual subtyping) between the zero-cost abstraction and the underlying representation type.

We could then add boxing as an enhancement later on, yielding some extra time to think about it and implement it.

Here's an example using views (with no support for implements, but an explicit boxing modifier box on the wrapper):

view V on T {
  ... // Methods as needed for `V`.
}

box struct C(V that) implements /*Whatever you want*/ {
  ... // Manually implemented members, where you want custom behavior.
  // Remaining members will be implicitly induced forwarders to `that`.
}

The struct C would then be filled in by the compiler. This would work a bit like a class declaring a noSuchMethod, where the compiler will generate noSuchMethod forwarders for every unimplemented member.

The difference is that C would receive a forwarding member for every member of V (calling the implementation in V), and a forwarding member for every member (which is not already handled as a forwarder to V) of an interface in the implements clause of C, with the combined member signature. It is a compile-time error if the resulting class isn't concrete (that is, some members aren't implemented at all).

I think this means that the boxing mechanism is made slightly more general (it could be used on any type, not just zero-cost abstractions), and we do get to specify the subtype relationships and check that they are satisfied, and we allow for some implementations to be provided by a mixin or a superclass, etc. etc.