Concept constraint syntax

[MattWindsor91]

In a recent meeting it was decided that the current overloading of the C# where syntax is too confusing: it causes where to mean two only-slightly-related concepts (pun unintended). We need to create a new syntax, but it's unclear which would be better.

Existing

A concept witness is introduced into a method or class as follows:

A Sum<A>(A[] xs) where NumA : Num<A> { /* ... */ }

Note that NumA does not appear in the type parameter list. This is the clue that makes the compiler realise this is a concept witness, and translate it to

A Sum<A, [ConceptWitness] NumA>(A[] xs) where NumA : struct, Num<A> { /* ... */ }

The fact that the semantics depends on whether NumA is in the type parameters or not is quite surprising!

Proposal 1: No syntax

Do not add any syntactic sugar: programmers must write

A Sum<A, [ConceptWitness] NumA>(A[] xs) where NumA : struct, Num<A> { /* ... */ }

Pros

• Simplest realistic change.
• No implicit type parameters, thus the number of type parameters in the angle brackets is always the number of type parameters, and also the number of type arguments to provide at use site.

  Cons

• The semantic changes by adding [ConceptWitness] are significant enough that the use of a literal attribute here seems odd.
• Verbose and ugly.

  Proposal 2: where-style syntax

Use the same sort of syntax as where, but with a different keyword. May need to engineer the correct keyword or keyword chord to use.

Some possibilities I like:

A Sum<A>(A[] xs) instance NumA : Num<A> { /* ... */ }
A Sum<A>(A[] xs) concept NumA : Num<A> { /* ... */ }
A Sum<A>(A[] xs) where instance NumA : Num<A> { /* ... */ }
A Sum<A>(A[] xs) where concept NumA : Num<A> { /* ... */ }
A Sum<A>(A[] xs) where implicit NumA : Num<A> { /* ... */ }
A Sum<A>(A[] xs) implicit instance NumA : Num<A> { /* ... */ }
A Sum<A>(A[] xs) implicit concept NumA : Num<A> { /* ... */ }
// ...

Pros

• Fairly simple change.
• Current code would transition across quite well.
• Can fairly easily be generalised to allow elision of witness names, eg A Sum<A>(A[] xs) instance Num<A>.

  Cons

• New syntax production means upheaval on public API, but it's additive.
• If we use a keyword chord beginning with where, we have a backtrack in the parser.
• Requires us to pin down a keyword: may break parsing, etc.
• Slightly verbose.

  Proposal 3: inline syntax

Add some sort of syntactic modifier to type parameters to pick them out as concept witnesses.

A Sum<A, NumA : Num<A>>(A[] xs) { /* ... */ }
A Sum<A, NumA = Num<A>>(A[] xs) { /* ... */ }
A Sum<A, instance NumA : Num<A>>(A[] xs) { /* ... */ }
A Sum<A, instance NumA = Num<A>>(A[] xs) { /* ... */ }
// ...

Pros

• Terse
• Preserves the property that the number of angle-bracketed things is the number of type parameters and arguments
• Not ambiguous with where

  Cons

• Quite invasive syntax change to type parameters.
• Not obvious what this syntax is doing.
• Different from any other language.
• Not obvious how this would work with witness name elision.

  Proposal 4: Haskell-style syntax

Add syntax similar to Haskell.

NumA : Num<A> => A Sum<A>(A[] xs) { /* ... */ }

Pros

• Terse
• Familiar to people using Haskell
• Can fairly easily be generalised to allow elision of witness names, eg Num<A> => A Sum<A>(A[] xs).

  Cons

• Quite a massive syntactic change
• Maybe ambiguous with expression-bodied members
• People might think this syntax means where
• Not very idiomatic C#

  Conclusion

Personally, I'm in favour of proposal 1 (mainly from an implementation point of view), but as I'm not used to the concerns of C# syntax design I'm not entirely sure this is the best way forwards.

Additional proposals and comments welcome.

[MattWindsor91]

A possible extension of proposal 2 is to allow syntax for pulling existing concept instances (either defined in methods/classes other than the current one but in scope, or ground instances) into the current scope as if they were witnessed by an implicit type parameter, eg:

void Foo<A>(A a, int I)
    implicit instance BarA : Bar<A> // normal witness, becomes a type parameter
    using instance BarInt // finds instance BarInt in scope and makes it available for resolution, no new type parameters
{
  // ...
}

Similarly, associated types could be given the pseudo-where treatment:

concept Set
    implicit type Element // becomes new type parameter <[AssociatedType] Element>
{
  // ...
}

instance SetInt : Set
   implicit type Element = int // does unknown magic to satisfy type parameter
{
  // ...
}

The syntax here is just a sketch, though.