[swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Jordan Rose]

> On Jun 1, 2016, at 14:18, Austin Zheng <austinzheng at gmail.com> wrote:
> 
> I'd also like to express my support for the proposal to delineate generic and existential syntax: all existentials must be written with Any<...>; generic type constraints cannot use it. I hope this will make it clear to people learning and using the language that, despite their superficial similarities, they are actually two different concepts.

This is definitely getting off-topic for this particular review, but I’ve come to agree with you. I can only speak for myself, but back when we were implementing protocols in Swift it felt great to eliminate the wedge between ’NSTableView *’ and ‘id <NSTableViewDelegate>’. But then we started using protocols for many more things in Swift, and it turns out that the simple use case of “I have a protocol-typed property” isn’t really the one worth optimizing for anymore. When they’re arguments, you more often than not might want to use them generically, and you should at least be thinking about that when you define a function.

Where we are today, the protocol-typed value is the obvious choice, and then you move to generics when the compiler tells you no. Having the choice be between these two:

func foo<T: SignedInteger>(value: T)
func foo(value: Any<SignedInteger>)

makes it a little more likely that someone will stop and think about picking the first.

(Then again, Joe’s talked about making the second use the ABI of the first anyway as an optimization, though that can backfire if the value is copied around a lot.)

I suppose a middle ground would restrict the protocol-name-only syntax to class-bound protocols, which are the most likely to be used in properties (“delegate-like protocols”). I’d be hesitant to restrict to “class-bound protocols without associated types” because we want adding an associated type to be a non-breaking change <http://jrose-apple.github.io/swift-library-evolution/#protocols> (if we can figure out how to do it).

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160601/4cc6d26d/attachment.html>