Generic type as generic constraint

[Nevin]

Okay, I’ve gone back through the Parameterized Extensions proposal, and based on the examples shown there I am led to the conclusion that it amounts to, essentially, syntactic salt for what I propose here.

The motivation section of that proposal contains exactly 2 examples, one of which is essentially identical to my motivation here, and the other is pure sugar independent of both proposals and could be implemented as such today.

Going through that proposal section by section:

Motivation

Parameterized Extensions

Motivation

Currently in Swift, one cannot give extensions generic parameters to build expressive generic signatures for new members. Consider the example:

// You can't really express this extension where any array whose element is an optional type.
// This doesn't work.
extension Array where Element is Optional {

This is the same motivation as for my thread here. The syntax they use to convey the idea is very similar to what I propose, except they have “is” in place of “:”.

// error: constrained extension must be declared on the unspecialized generic
//        type 'Pair' with constraints specified by a 'where' clause
extension Pair<Int> {

This is pure sugar, not a parameterized extension. We could make this valid today by simply teaching the compiler to interpret it as extension Pair where Element == Int.

• • •

Proposed solution

Proposed solution

Extensions can now be decorated with a generic parameter list to be used with constructing a generic signature when extending types. Using the array of optionals example above, we can now write:

extension<T> Array where Element == Optional<T> {
 // ...
}

This is the same functionality as I propose, but with a more awkward spelling. It is equivalent to my “extension Array where Element: Optional”.

// Extend all arrays whose elements are optionals whose wrapped type conforms to FixedWidthInteger
extension<T: FixedWidthInteger> Array where Element == T? {

As before, this is isomorphic to what I propose. There is no functional difference between the above and its equivalent in non-parameterized syntax:

extension Array where
  Element: Optional,
  Element.Wrapped: FixedWidthInteger
{

It is true that the <T> form is shorter, but at the same time the second version reads more naturally and better matches what we already write for protocol extensions with multiple constraints.

Extending types with same type requirements

// Extend array whose element type is an optional T
extension<T> Array<T?> {}

This is just sugar for the first example. Again it is shorter than “extension Array where Element: Optional”, but not necessarily as intuitive.

Extending specialized types

// We don't need to know that Array's only generic parameter is named Element
// This is especially useful for types that have not so great generic parameter
// names, such as T, U, V, etc.
extension Array<String> {}

This is the pure-sugar example again. It is independent of parameterized extensions.

// Extend Array where the element type is an optional T
extension<T> [T?] {}

This is just a sugared form of the ongoing example, which is still equivalent to my proposed “extension Array where Element: Optional”.

• • •

Detailed design

Banning generic parameters extensions

When one extends the generic parameter that was declared in the extension, the compiler will diagnose that it's currently unable to do so.

extension<T> T {} // error: cannot extend non-nominal and non-structural type 'T'

The parameterized extensions proposal needs a special-case to prohibit this, whereas with my proposal it simply follows from the existing restriction on extending Any.

Conditional Conformance

Parameterized extensions allow for some very neat generic signatures, including conditional conformance.

// If Array's Element type is Equatable, conform to Equatable
extension<T: Equatable> [T]: Equatable {}

This is isomorphic to what is already done today: extension Array: Equatable where Element: Equatable. I do not see any benefit to introducing a new, punctuation-dense syntax for what can already be written clearly with words.

• • •

ABI stability

Effect on ABI stability

Rewriting your conditional conformance to use parameterized extensions instead would break ABI.

// Before
extension Array: Equatable where Element: Equatable {}

// After (ABI broke)
extension<T: Equatable> [T]: Equatable {}

…and here we see an actual drawback to introducing the second parallel syntax. No such problem exists with my proposal, because there would remain only one way of writing this.

• • •

Future Directions

Future Directions

Right now, extending generic parameters are banned. One could extend a generic parameter to add members to all types in the future.

// Extend every type to include a instance member named `abc`
extension<T> T {
  func abc() {}
}

If we were to decide to allow extensions of all types, the natural spelling would be extension Any. Once again, parameterized extensions would create a parallel syntax with no benefit.

// Extend every type that conforms to ProtoA to conditionally conform to ProtoB as well.
extension<T: ProtoA> T: ProtoB {}

This is a new and powerful feature. I think it is worth considering this functionality on its own merits. Notably, this is not actually part of the parameterized extensions proposal: it is a potential future direction.

If we decide we want this, then we can come up with a good spelling for it at that time. I do not think we should salt the syntax for using generic types as generic constraints, based on the mere possibility of a future feature.

// Extend tuple to conform to Equatable where all of its Elements conform to Equatable
extension<...Elements: Equatable> (Elements...): Equtable {}

This is covered by the separate Variadic Generics proposal.

• • •

My ultimate takeaway is that the actual motivating problem to be solved, is that generic types cannot currently be used as generic constraints.

If we could write

extension Dictionary where Value: Optional

and have access to Value.Wrapped within that extension, there would be no need for the parameterized extensions proposal. Its motivating use-case would be solved.