Improving the UI of generics

[anandabits (Matthew Johnson)]

This is all fantastic! I am a heavy user of the generics system and it would make a lot of my code much cleaner and lighter weight syntactically. However, even more exciting is how this makes the generics system much more approachable, especially to programmers who are not yet comfortable with generics.

I very strongly like the idea of using some and any to provide a syntactic symmetry and equivalent weight to type and value level abstractions. This will encourage people to learn their different semantics and make the appropriate choice instead of choosing existentials because the syntax is simpler (and therefore easier to understand). Requiring any would be source breaking but migration should be possible. The benefits are worth doing this.

@Joe_Groff

There are a number of different directions we could go here. For one, we could allow the argument value names to be used in place of type variables, with maybe a placeholder name like return for the unnamed return value:

func concatenate(a: some Collection, b: some Collection) -> some Collection
  where type(of: a).Element == type(of: b).Element,
        type(of: return).Element == type(of: b).Element

or we could look at Rust again, which has a convenient Trait<AssocType = T> notation for constraining associated types. An analogous feature in Swift might allow simple associated type constraints to be expressed without a where clause at all:

func concatenate<T>(a: some Collection<.Element == T>, b: some Collection<.Element == T>)
  -> some Collection<.Element == T>

I think we should support both of these in the fullness of time. The Rust-inspired syntax is lighter weight and eliminates indirection in the same way that some syntax does. One of the particularly nice things about this syntax is that in cases such as the above example it really highlights the fully parametric polymorphism that this function exhibits in the same manner as the original example.

However it does not support the full generality of constraints we might want to express. We shouldn’t have to introduce explicit type variables just to express these constraints. The type(of:) syntax makes perfect sense here.

The only topic I expected to see in this document that wasn’t present is opaque typealias. That feature was pretty heavily discussed in the opaque typealias threads. What was the reason for omitting it from this document?

Finally, if this documentation is intended to layout the roadmap for generics work over the next year or two there are a couple of other things I think we should be considering. In terms of large type system features, generic associated types would be an incredible tool to have available. It would also be nice to see some smaller generics features such generalized supertype constraints, callable constraints and possibly conditional default arguments be represented as well. (If this is not intended to be a complete roadmap please feel free to ignore the paragraph.)