<html><head><style>
body {
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
padding:1em;
margin:auto;
background:#fefefe;
}
h1, h2, h3, h4, h5, h6 {
font-weight: bold;
}
h1 {
color: #000000;
font-size: 28pt;
}
h2 {
border-bottom: 1px solid #CCCCCC;
color: #000000;
font-size: 24px;
}
h3 {
font-size: 18px;
}
h4 {
font-size: 16px;
}
h5 {
font-size: 14px;
}
h6 {
color: #777777;
background-color: inherit;
font-size: 14px;
}
hr {
height: 0.2em;
border: 0;
color: #CCCCCC;
background-color: #CCCCCC;
display: inherit;
}
p, blockquote, ul, ol, dl, li, table, pre {
margin: 15px 0;
}
a, a:visited {
color: #4183C4;
background-color: inherit;
text-decoration: none;
}
#message {
border-radius: 6px;
border: 1px solid #ccc;
display:block;
width:100%;
height:60px;
margin:6px 0px;
}
button, #ws {
font-size: 12 pt;
padding: 4px 6px;
border-radius: 5px;
border: 1px solid #bbb;
background-color: #eee;
}
code, pre, #ws, #message {
font-family: Monaco;
font-size: 10pt;
border-radius: 3px;
background-color: #F8F8F8;
color: inherit;
}
code {
border: 1px solid #EAEAEA;
margin: 0 2px;
padding: 0 5px;
}
pre {
border: 1px solid #CCCCCC;
overflow: auto;
padding: 4px 8px;
}
pre > code {
border: 0;
margin: 0;
padding: 0;
}
#ws { background-color: #f8f8f8; }
.bloop_markdown table {
border-collapse: collapse;
font-family: Helvetica, arial, freesans, clean, sans-serif;
color: rgb(51, 51, 51);
font-size: 15px; line-height: 25px;
padding: 0; }
.bloop_markdown table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
.bloop_markdown table tr:nth-child(2n) {
background-color: #f8f8f8; }
.bloop_markdown table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr th :first-child, table tr td :first-child {
margin-top: 0; }
.bloop_markdown table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }
.bloop_markdown blockquote{
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777; }
blockquote > :first-child {
margin-top: 0; }
blockquote > :last-child {
margin-bottom: 0; }
code, pre, #ws, #message {
word-break: normal;
word-wrap: normal;
}
hr {
display: inherit;
}
.bloop_markdown :first-child {
-webkit-margin-before: 0;
}
code, pre, #ws, #message {
font-family: Menlo, Consolas, Liberation Mono, Courier, monospace;
}
.send { color:#77bb77; }
.server { color:#7799bb; }
.error { color:#AA0000; }</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="bloop_markdown"><p>One more thing, I would also add the ability to allow something like this:</p>
<pre><code class="swift">protocol A {}
protocol B {}
// Here `type` can be `protocol`, `class`, `struct` or `enum`.
type C: any<A, B> {}
</code></pre>
<p>Where today is only possible to express something like this:</p>
<pre><code class="swift">protocol A {}
protocol B {}
typealias AB = any<A, B>
// Here `type` can be `protocol`, `class`, `struct` or `enum`.
type C: AB {}
</code></pre>
<p>This is a lack of functionality.</p>
<p></p></div><div class="bloop_original_html"><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1463832581428915968" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 21. Mai 2016 bei 05:16:24, Matthew Johnson via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div></div><div>
<title></title>
<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="">
<blockquote type="cite" class="">
<div class=""><span 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:</span></div>
<span class=""><br class=""></span>
<div class="">
<div style="word-wrap:break-word" class="">
<div class=""><span class="">(Trying to move the conversation back
to this thread to un-hijack Adrian's thread.)</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span 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.</span></div>
</div>
</div>
</blockquote>
<div class=""><span class=""><br class=""></span></div>
<div class="">Thanks for the summary. I think this is
helpful. </div>
<span class=""><br class=""></span>
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap:break-word" class="">
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">Any<> pros:</span></div>
<div class=""><span 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)</span></div>
<div class=""><span class="">- Having 'Any<>' allows us to
keep the well-established 'Any' without having to typealias to
'any' or 'any<>’ forms</span></div>
</div>
</div>
</blockquote>
<div class=""><span class=""><br class=""></span></div>
<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=""></span>
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap:break-word" class="">
<div class=""><span 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</span></div>
<div class=""><span class="">- In the future, AnySequence and
friends can be replaced with, e.g.
Any<Sequence>.</span></div>
</div>
</div>
</blockquote>
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap:break-word" class="">
<div class=""><span 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.</span></div>
</div>
</div>
</blockquote>
<div class=""><span class=""><br class=""></span></div>
<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=""></span>
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap:break-word" class="">
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">any<> pros:</span></div>
<div class=""><span 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.</span></div>
</div>
</div>
</blockquote>
<div class=""><span class=""><br class=""></span></div>
<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=""></span>
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap:break-word" class="">
<div class=""><span 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.</span></div>
</div>
</div>
</blockquote>
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap:break-word" class="">
<div class=""><span 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.</span></div>
</div>
</div>
</blockquote>
<div class=""><span class=""><br class=""></span></div>
<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=""></span>
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap:break-word" class="">
<div class=""><span 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'</span></div>
<div class=""><span class="">- any is a keyword, and keywords are
lower case. Perhaps consistency in this matter is more
important.</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">Any other thoughts? I will submit an
amendment tonight if people are okay with this.</span></div>
</div>
</div>
</blockquote>
<div class=""><span class=""><br class=""></span></div>
<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=""></span>
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap:break-word" class="">
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">Austin</span></div>
<div class=""><span class=""><br class=""></span></div>
<span class=""><br class=""></span>
<div class="">
<blockquote type="cite" class="">
<div class=""><span 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:</span></div>
<span class=""><br class=""></span>
<div class="">
<div dir="ltr" class=""><span class="">Hello all,</span>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span 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.</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span 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></span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">Best,</span></div>
<div class=""><span class="">Austin</span></div>
</div>
</div>
</blockquote>
</div>
<span class=""><br class=""></span></div>
</div>
</blockquote>
</div>
<br class=""></div>
</blockquote>
</div>
<br class=""></div>
</div>
</blockquote>
</div>
<br class="">
_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>