Roles WG 2023-02-15

Syntax for base type list

In the proposal so far, we have a single base type list, which starts with an underlying type and then continues with a mix of roles and interfaces.

role R : UnderlyingType, BaseRole1, Interface1, BaseRole2, Interface2

This feels complicated and error-prone.
For example, you might not notice that you forgot to specify an underlying type since interfaces are allowed as underlying types.

role R : IUnderlyingInterface, Interface1, Interface2

Options:

1. Keep as-is single list (underlying type followed by base roles followed by interfaces) We might make this more readable by requiring some ordering of groups (don't mix base roles and interfaces). But this seems stylistic and requires some decoder ring knowledge. The readability issue may be mitigated by naming conventions (interfaces have I).
2. No ordering requirement for base roles and interfaces Users can organize the list themselves
3. allow optional underlying type when a base role is present, ordering of groups role R : BaseRole(s), Interface(s) An issue is that order now affects meaning: role R : BaseRole1, Interface1 vs. role R : Interface1, BaseRole1
4. Keyword for underlying type view VJsonView on type : views, interfaces view VCustomer extends type : view, interfaces view VJsonView of type : views, interfaces This provides an advantage for partials (keyword allows making underlying type optional with less ambiguity):
   partial R : UnderlyingType, Interface1 partial R : Interface2 (currently error since missing underlying type) We could also deal with an optional underlying type when base role(s) is present:
   view VCustomer : views, interfaces // infer extension of type : views, interfaces // optional extension name role of type ... // disallowed

Decision: let's go with (4)

What keyword for underlying type?

Here are some keywords we considered:

1. extension E of U
2. extension E extends U (too verbose)
3. extension E on U
4. extension E for U
5. extension E over U
6. this E of U
7. extension E is U
8. extension E override U (misleading since no virtual/inheritance)
9. extension E using U (two meanings for using already, not intent)
10. extension E from U

A few keywords stand out as potential candidates:
of suggests a property of the underlying thing
on suggests something added "on top of"
for is more like natural/English language (we have extensions for this type)

Here's what those could look like in context:

1. role R of U
2. view V of U
3. role R on U
4. view V on U
5. view V for U
6. extension V for U
7. extension Extension<T> for T

Decision: let's go with for. of would be second choice, on third.

Keyword for declaration of roles

We've considered a few candiates so far, but need a firmer decision since we're working on implementation.

1. role
2. view (this unfortunately already has connotations in various fields, from databases, UI, etc, but some of those can be misleading)
3. shape
4. alias (ambiguity with using aliases; empty roles are better aliases)
5. modifiers implicit and explicit:

• A. explicit extension Role for U (it's a bit long-winded but makes it clear that they are variations of same feature)
• B. explicit view Role for U, implicit view Extension for U

Decision: let's go with 5A