# 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
