<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 1, 2016, at 14:18, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><br class=""></div><div>This is <i class="">definitely</i> 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 <i class="">more often than not</i> might want to use them generically, and you should at least be <i class="">thinking</i> about that when you define a function.</div><div><br class=""></div><div>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:</div><div><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div>func foo<T: SignedInteger>(value: T)</div><div>func foo(value: Any<SignedInteger>)</div></blockquote><div class=""><br class=""></div><div class="">makes it a little more likely that someone will stop and think about picking the first.</div><div class=""><br class=""></div><div class="">(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.)</div><div class=""><br class=""></div><div class="">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 <a href="http://jrose-apple.github.io/swift-library-evolution/#protocols" class="">adding an associated type to be a non-breaking change</a> (if we can figure out how to do it).</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div></body></html>