<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 May 20, 2016, at 10:07 PM, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">These aren't really my points, I just copied them out of the other sub-thread. I'm sure there will be a separate review period, during which many more people will probably join in with their opinions :).</div></div></blockquote><div><br class=""></div><div>I understand that. You asked for any other thoughts before you update your proposal. I am sharing my thoughts. :) Feel free to use them in the proposal if desired.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Austin</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, May 20, 2016 at 7:59 PM, Matthew Johnson <span dir="ltr" class=""><<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On May 20, 2016, at 9:10 PM, Austin Zheng <<a href="mailto:austinzheng@gmail.com" target="_blank" class="">austinzheng@gmail.com</a>> wrote:</div><br class=""><div class=""><div style="word-wrap:break-word" class=""><div class="">(Trying to move the conversation back to this thread to un-hijack Adrian's thread.)</div><div class=""><br class=""></div><div class="">In terms of Any<> vs any<>, I don't have any strong feelings and I think there are good arguments on both sides. I'm going to leave the proposal as Any<> but put a section in the 'Alternatives' discussing Any<> vs any<>, so that if it does go up for review the core team can review arguments and maybe choose one they like.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Thanks for the summary. I think this is helpful. </div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class="">Any<> pros:</div><div class="">- The convention is to capitalize types. 'Any<A, B>' is immediately apparent as a type, and looks like a type when used in places where types would be used (like function signatures)</div><div class="">- Having 'Any<>' allows us to keep the well-established 'Any' without having to typealias to 'any' or 'any<>’ forms</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">How so? you can’t just use `protocol` naked today. You have to say `protocol<>`. `Any` is a typealias for that. This means we either have a typealias, we type out `Any<>` or we type out `any<>`. We don’t get to just type `Any` or `any` without a typealias just because we change the keyword.</div><div class=""><br class=""></div><div class="">And I do agree that typealias for existentials should be capitalized. These are types and behave identically to any other type.</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class="">- any is a keyword, but an argument can be made that keywords that fit into a particular syntactic slot should be capitalized like normal members of that slot. Any<> fits into the slot of types, so it should be named like a type</div><div class="">- In the future, AnySequence and friends can be replaced with, e.g. Any<Sequence>.</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class="">This increases discoverability of existential features, like a future "Any<Sequence where .Element == Int>". A number of developers have mentioned that they suspect protocol<> is rarely used, although GitHub's search makes it impossible to quantify.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">If protocol<> is rarely used it is probably because it is a very limited feature at this point. It becomes extremely useful when we can constrain associated types. </div><div class=""><br class=""></div><div class="">When that is possible and the community shares knowledge about how to use it it will become a widely used feature. I don’t think upper / lower case or `typealias AnySequnce<T> = Any<Sequence where .Element == T>` will make much difference either way.</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class="">any<> pros:</div><div class="">- any<>'s lower case 'a' distinguishes it from other generic types that use similar syntax, such as "Array<Int>". Perhaps developers, especially those new to Swift, will be confused as to why "Any<A, B>" isn't a generic type, but "Dictionary<A, B>" is. </div></div></div></blockquote><div class=""><br class=""></div></span><div class=""><div class="">The reason this is important is that generic types can be used in ways that Any cannot. Thus the likely point of confusion is why the following is not valid:</div><div class=""><br class=""></div><div class="">struct Foo<T, U> {<br class=""> func foo(bar: Any<T, U>) { ... }<br class="">}</div></div><div class=""><br class=""></div><div class="">If we use lowercase it gives the user a hint as to why they might not be able to use it in all of the same ways as a generic type, <i class="">especially</i> because Swift is developing strong and consistent conventions for keywords. If we use uppercase here, not only do we introduce potential confusion in this case, we <i class="">also</i> water down the meaning of those conventions and make the language slightly less predictable. (i.e. users might wonder: are there other uppercase generic-type-like constructs that don’t quite behave like normal generic types?)</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class="">New developers aside, it may be jarring to have to mentally 'context switch' between Any<A, B> as an existential, and AnythingButAny<A, B> as a generic type.</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class="">- any's lower case 'a' makes it clear to users it's not a 'normal' type, but rather a construction that can be used as a type in some cases, and can't be used everywhere a concrete type can.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Existential types can be used anywhere concrete types can. The difference is that Any as a<b class=""> type constructor </b>behaves much differently than other type constructors (generic structs, enums, and classes). </div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class="">- 'any' isn't a specific type - it's a kind of type (an existential), and this spelling fits better with the other 'kind' names: 'class', 'struct', 'enum', 'protocol'</div><div class="">- any is a keyword, and keywords are lower case. Perhaps consistency in this matter is more important.</div><div class=""><br class=""></div><div class="">Any other thoughts? I will submit an amendment tonight if people are okay with this.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I have one additional thought. Brent’s rule is based on *exempting* keywords from the usual rule of lowercase. IMO that exemption should be reserved for cases where the keyword in question can be used in <b class="">all</b> of the same was that the similar syntactic form can be used. I believe the fact that this is not the case for Any is a strong argument to preclude it from receiving the exemption.</div><div class=""><br class=""></div><div class="">To be perfectly honest, I do prefer `Any` from an aesthetic / readability standpoint. But I also think the consistency and usability arguments point in the other direction.</div><div class=""><br class=""></div><div class="">When all has been decided I will happily use whatever is decide in my own code. :-)</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class="">Austin</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 18, 2016, at 10:35 PM, Austin Zheng <<a href="mailto:austinzheng@gmail.com" target="_blank" class="">austinzheng@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Hello all,<div class=""><br class=""></div><div class="">Swift 3.0 focuses on making breaking changes that prepare the way for features to be introduced in future releases. In that spirit, I would like to solicit feedback on a very simple proposal: renaming 'protocol<>' to 'Any<>', as described in the 'Completing Generics' manifesto.</div><div class=""><br class=""></div><div class="">The proposal can be found here: <a href="https://github.com/austinzheng/swift-evolution/blob/az-protocol-to-any/proposals/XXXX-any-as-existential.md" target="_blank" class="">https://github.com/austinzheng/swift-evolution/blob/az-protocol-to-any/proposals/XXXX-any-as-existential.md</a></div><div class=""><br class=""></div><div class="">Best,</div><div class="">Austin</div></div>
</div></blockquote></div><br class=""></div></div></blockquote></span></div><br class=""></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>