It is a wonderful document, with many of the previous discussions being neatly organized.
The ORT discussion was very complicated, but I think the extension of type system by concept of reverse generics and concise notation with the some keyword are very beautiful.
If the some keyword is implemented, users will gradually notice this ease of use and spread. And I think that the speed of learning that Swift beginners use Generics will accelerate. Reducing the indirection of expressivity by one is quite powerful.
In fact, I was looking at these arguments, and I thought that Existentials must be attached keyword any, and I was wondering if I would like to post that pitch.
The reason I was wavered was that there was an ambiguous memory like I saw a reference to the notation Any<Base, Proto1> when there was a discussion of subclass existential (SE-0156, swift-evolution/0156-subclass-existentials.md at master · apple/swift-evolution · GitHub) at the time, and I don't know the details so I thought that it might be a story reached conclusion.
So, I was happy to mention any mandatory idea in this thread.
However, when it comes to that, it is the any notation for subclass existence.
There are likely to be several possibilities:
let p1: any UIViewController & UITableViewDelegate & UITableViewDataSource
let p2: UIViewController & any UITableViewDelegate & any UITableViewDataSource
let p3: UIViewController & any(UITableViewDelegate & UITableViewDataSource)
Considering transformation from a simple UIViewController type variable, p2 or p3 seems to be good, but p2 looks like an intersection type between Existentials. This construction is not wrong either, but strictly it will be one existential that satisfies two protocols. p3 looks good in that respect, but it is wierd to write in parentheses. This part will need to be discussed in the future.
The point that almost all intermediate level players in Swift squeeze in is that “protocol has two functions of existential and protocol”. I think this is the biggest cause of confusion that two completely different concept appear in the same way in appearance. So I think we should change the look. This is achieved by any requirement.
Another difficulty is the existential self-conformance problem. Understanding this is one of the keys to becoming a Swift expert. In this regard, I thought that the existential-only extensions listed are very nice. The current Swift has become more difficult due to the special support of the Error type, but this is not special if it is defined as follows.
extension any Error : Error {}
In addition, user-defined protocols can also be made self-conformance by themselves. And if self-conformance can not be achieved due to the presence of static members, etc., the code becomes a compilation error, and the user can learn the theory from the error.
Equatable is a very good example in this respect, and in the process of giving an implementation of ==, we can touch the nature of the difficulties of the type system of self-conformance. It is necessary to compare different types dynamically because Equatable is essentially the same type comparison, but existential is super type, and it is necessary to consider various implicit conversions in Swift runtime.
I think that the ease of use of Swift will evolve at a stretch if we go in the direction that this summary shows, including the open notation of existential. I am very looking forward to it.