Unifying structs and interfaces

[MarkMcCulloh]

Started a discussion in #4961

Reposting my comment below:

In addition to this change, I think we should evaluate the purpose of structs. In terms of type expressiveness, this change makes structs a subset of interfaces. structs no longer serve a purpose that can't be solved by the compiler itself. Why not get rid of structs and support interfaces everywhere structs are used i.e.:

// maybe we stop calling them interfaces and call them `type` or `shape` instead
interface Whatever {
  field: num;
  func(): void;
}

let x = Whatever {
  field: 2,
  func() {}, // or `func: () => {},` I guess
}

If the concern is "structs are special because they provide a guarantee of no functions/behavior", I would say:

1. We're statically typed, the compiler knows if interfaces do/don't have functions
2. This isn't even true to begin with, as structs can have class instances as fields

---

and also a response from @eladb :

there's a fundamental difference between behavioral interfaces and data structures in my mind. i don't think structs and interfaces are the same thing. for example, Struct.fromJson doesn't make any sense on interfaces.

---

My response to the response:

there's a fundamental difference between behavioral interfaces and data structures in my mind. i don't think structs and interfaces are the same thing.

The key part of this is that the difference is in the mind, they don't actually need to do anything different. Functionally structs and interfaces "can" be the same thing. That fact that you decided that interfaces are behavioral is arbitrary once we allow properties. It means I can create an interface with only properties. Is that behavioral? Sure, but then structs are also behavioral.

Struct.fromJson doesn't make any sense on interfaces.

If you're saying that because interfaces allow functions, then I would argue it doesn't make sense on structs either because structs can still contain functions (via classes). If you have an interface with only properties, sure why not allow fromJson. Either way, this can be statically determined.

I think we're on the same page with interfaces (no need to repeat that they are behavioral or pointing to anything "fundamental", I understand), my concern is with structs. They aren't limited enough. Structs should not allow classes.
If we don't restrict them further, I would argue there is too much overlap between structs and interfaces and we might as well get rid of structs.

[eladb]

Yes, structs should be more limited and we will add these constraints in the future, but I don't think we should get rid of them because we can't fully express these concerns yet.

In my mind the difference between interfaces and structs is that interfaces represent objects that must be passed by reference while structs represent objects that can be passed by-value (by bitwise copying all the data).

Currently, we can't really express this constraint in the language but ideally structs should only reference immutable objects. Currently, we don't really have immutability modeled for user-defined types only for the built-in collection types, but once we introduce that, then I would add that constraint to structs.

[Chriscbr]

The idea of combining structs/interfaces is starting to grow on me.

Here's a (slightly modified) proposal that uses a new word, "shape", to try to put aside any preconceived assumptions you have from words like "interface" or "struct". But the name isn't essential to the design.

---

Instead of interfaces or structs, Winglang supports shapes. A shape is a contract that allows you specify that a value has a set of publicly available members. A shape is defined like so:

shape AwsInstance {
  publicIp: str?;
  start: inflight(): void;
  stop: inflight(): void;
}

This syntax emphasizes that the members start and stop don't have any particular phase associated with them, only their values do.

A shape does not have a phase associated with it. But function members defined on the shape may have phases, like any other function annotations.

Shapes are implemented by classes. A shape can by satisfied by an instance of a preflight class, and inflight class, or an anonymous class object:

class A impl AwsInstance {
  publicIp: str?;
  inflight start(): void { ... }
  inflight stop(): void { ... }
}

// preflight class object
let a: AwsInstance = new A();

inflight class B impl AwsInstance {
  ...
}

// inflight class object
let b: AwsInstance = new B();

// "anonymous class object"
let c = AwsInstance {
  publicIp: nil,
  start: inflight () => { ... },
  stop: inflight () => { ... },
};

// equivalent to...
/*
class $AwsInstance1 impl AwsInstance {
  publicIp: str = nil;
  inflight start() { ... }
  inflight stop() { ... }
}
let c = new $AwsInstance1();
*/

Shapes can extend other shapes. Shape members can only add members - a shape cannot override members of shapes it extends:

shape Foo {
  foo: str;
}

shape Bar extends Foo {
  foo: str;
}

If a shape has preflight methods or if it extends the "construct" shape, then it cannot be implemented by an inflight class:

shape IBucket extends construct.Construct {
  addObject: (): void; // implicitly preflight
}

inflight class B impl IBucket { // error: members "addObject" of the shape IBucket prevent it being implemented by an inflight class
  ...
}

// alternate syntax:
construct shape IBucket {
  ...
}

If a function parameter has a shape type, it can accept any value that implements that shape:

let restartInstance = inflight (inst: AwsInstance) => {
  inst.stop();
  inst.start();
};

Shapes can serve additional purposes. One use for shapes are named parameters in method signatures or class constructors:

shape FooProps {
  prop1: bool;
  prop2: inflight (): void;
}

class Foo {
  new(props: FooProps) {}
}

new Foo(prop2: inflight () => { ... }, prop1: true);

If the json modifier is added to a shape declaration, then .fromJson() and .toJson() methods will be automatically available on the shape type:

json shape Order {
  id: str;
  items: Array<str>;
}

Order.fromJson(...);

The json modifier can only be added to shapes whose member types are serializable over the wire.

[eladb]

I really like the idea of introducing protocol and data protocol and getting rid of structs and interfaces. I think that's a better model.

[Chriscbr]

Another open question -- we recently introduced inflight interfaces as a complement to [implicitly-]preflight interfaces -- how does that factor in here?

[eladb]

In a sense an inflight interface is merely sugar for interface extends std.IResource, correct?

So either we just continue to support this for protocols (inflight protocol) or:

protocol Boo extends std.IResource

[thoroc]

A shape is a contract

Sorry to wander in a bit late in the conversation, but since you are talking about contract and using the keyword shape, would it be more sensical to just use the keyword contract instead?

I appreciate if you've made the changes and your mind up and this suggestion is only adding noise.

[Chriscbr]

@thoroc No worries - naming suggestions are welcome. contract is also reasonable. I think to my ears one benefit of shape is it connotes the structural typing behavior (if two shapes have the same contents, then they're interchangeable). But I'm also liking the sound of protocol