Improving the UI of generics

[koher (Yuta Koshizawa)]

I really love the direction. some and any seems perfect keywords. I think explicit existential types are worth breaking source compatibility. It also helps to notify people who are familiar with languages like Java that protocols in Swift are different from interfaces in those languages when they learn Swift.

@Joe_Groff

To begin with, a particularly useful cross-section of functionality is captured in SE-244, opaque result types, which introduces the some Protocol syntax for type-abstracted return types. This roughly follows the progression of impl Trait in Rust, where it was first introduced only for return types, then was generalized to be able to appear structurally in both argument and return types. We think this is a reasonable first step because it directly addresses the biggest functionality gap in the generics model.

Supporting "reverse generics" first seems better for me because

1. Swift has already supported generics. I think having generics and "reverse generics" in a transition period makes sense better than having only generics and opaque result types.
2. I think the some syntax can be understood easily when it is considered as sugar of generics and "reverse generics". Threads about SE-0244 shows a lot of people got confused to understand opaque result types directly without the concept of "reverse generics".
3. "reverse generics" is more expressive. For example, a function below can't be implemented with the some syntax in my understanding. Tackling "reverse generics" first can prevent lack of consideration about internal implementation.

func makeAnimals() -> <A: Animal> (A, A) {
    return (Cat(), Cat())
}