<div dir="ltr">These aren&#39;t really my points, I just copied them out of the other sub-thread. I&#39;m sure there will be a separate review period, during which many more people will probably join in with their opinions :).<div><br></div><div>Austin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 20, 2016 at 7:59 PM, Matthew Johnson <span dir="ltr">&lt;<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On May 20, 2016, at 9:10 PM, Austin Zheng &lt;<a href="mailto:austinzheng@gmail.com" target="_blank">austinzheng@gmail.com</a>&gt; wrote:</div><br><div><div style="word-wrap:break-word"><div>(Trying to move the conversation back to this thread to un-hijack Adrian&#39;s thread.)</div><div><br></div><div>In terms of Any&lt;&gt; vs any&lt;&gt;, I don&#39;t have any strong feelings and I think there are good arguments on both sides. I&#39;m going to leave the proposal as Any&lt;&gt; but put a section in the &#39;Alternatives&#39; discussing Any&lt;&gt; vs any&lt;&gt;, 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><br></div></span><div>Thanks for the summary.  I think this is helpful.  </div><span class=""><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div><br></div><div>Any&lt;&gt; pros:</div><div>- The convention is to capitalize types. &#39;Any&lt;A, B&gt;&#39; 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>- Having &#39;Any&lt;&gt;&#39; allows us to keep the well-established &#39;Any&#39; without having to typealias to &#39;any&#39; or &#39;any&lt;&gt;’ forms</div></div></div></blockquote><div><br></div></span><div>How so?  you can’t just use `protocol` naked today.  You have to say `protocol&lt;&gt;`.  `Any` is a typealias for that.  This means we either have a typealias, we type out `Any&lt;&gt;` or we type out `any&lt;&gt;`.  We don’t get to just type `Any` or `any` without a typealias just because we change the keyword.</div><div><br></div><div>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><blockquote type="cite"><div><div style="word-wrap:break-word"><div>- 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&lt;&gt; fits into the slot of types, so it should be named like a type</div><div>- In the future, AnySequence and friends can be replaced with, e.g. Any&lt;Sequence&gt;.</div></div></div></blockquote><blockquote type="cite"><div><div style="word-wrap:break-word"><div>This increases discoverability of existential features, like a future &quot;Any&lt;Sequence where .Element == Int&gt;&quot;. A number of developers have mentioned that they suspect protocol&lt;&gt; is rarely used, although GitHub&#39;s search makes it impossible to quantify.</div></div></div></blockquote><div><br></div></span><div>If protocol&lt;&gt; 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><br></div><div>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&lt;T&gt; = Any&lt;Sequence where .Element == T&gt;` will make much difference either way.</div><span class=""><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div><br></div><div>any&lt;&gt; pros:</div><div>- any&lt;&gt;&#39;s lower case &#39;a&#39; distinguishes it from other generic types that use similar syntax, such as &quot;Array&lt;Int&gt;&quot;. Perhaps developers, especially those new to Swift, will be confused as to why &quot;Any&lt;A, B&gt;&quot; isn&#39;t a generic type, but &quot;Dictionary&lt;A, B&gt;&quot; is. </div></div></div></blockquote><div><br></div></span><div><div>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><br></div><div>struct Foo&lt;T, U&gt; {<br>    func foo(bar: Any&lt;T, U&gt;) { ... }<br>}</div></div><div><br></div><div>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>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>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><blockquote type="cite"><div><div style="word-wrap:break-word"><div>New developers aside, it may be jarring to have to mentally &#39;context switch&#39; between Any&lt;A, B&gt; as an existential, and AnythingButAny&lt;A, B&gt; as a generic type.</div></div></div></blockquote><blockquote type="cite"><div><div style="word-wrap:break-word"><div>- any&#39;s lower case &#39;a&#39; makes it clear to users it&#39;s not a &#39;normal&#39; type, but rather a construction that can be used as a type in some cases, and can&#39;t be used everywhere a concrete type can.</div></div></div></blockquote><div><br></div></span><div>Existential types can be used anywhere concrete types can.  The difference is that Any as a<b> type constructor </b>behaves much differently than other type constructors (generic structs, enums, and classes).  </div><span class=""><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div>- &#39;any&#39; isn&#39;t a specific type - it&#39;s a kind of type (an existential), and this spelling fits better with the other &#39;kind&#39; names: &#39;class&#39;, &#39;struct&#39;, &#39;enum&#39;, &#39;protocol&#39;</div><div>- any is a keyword, and keywords are lower case. Perhaps consistency in this matter is more important.</div><div><br></div><div>Any other thoughts? I will submit an amendment tonight if people are okay with this.</div></div></div></blockquote><div><br></div></span><div>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>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><br></div><div>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><br></div><div>When all has been decided I will happily use whatever is decide in my own code.  :-)</div><span class=""><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div><br></div><div>Austin</div><div><br></div><br><div><blockquote type="cite"><div>On May 18, 2016, at 10:35 PM, Austin Zheng &lt;<a href="mailto:austinzheng@gmail.com" target="_blank">austinzheng@gmail.com</a>&gt; wrote:</div><br><div><div dir="ltr">Hello all,<div><br></div><div>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 &#39;protocol&lt;&gt;&#39; to &#39;Any&lt;&gt;&#39;, as described in the &#39;Completing Generics&#39; manifesto.</div><div><br></div><div>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">https://github.com/austinzheng/swift-evolution/blob/az-protocol-to-any/proposals/XXXX-any-as-existential.md</a></div><div><br></div><div>Best,</div><div>Austin</div></div>
</div></blockquote></div><br></div></div></blockquote></span></div><br></div></blockquote></div><br></div>