<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Okay now I feel like we’re merging everything we came up until now :D I’d love to see something like this happen to Swift, because `Any` seems to be a really powerful beast one day.</div><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><div id="bloop_customfont" style="color: rgb(0, 0, 0); margin: 0px;"><span style="font-family: Helvetica, Arial; font-size: 13px;">One quick question: Do we really need this </span><font face="Helvetica">"<span style="color: rgb(51, 51, 51);">This must be the first requirement, if present.</span>“?</font></div><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><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">I’d say the compiler should reorder all types as it wants to. Current protocol<> already doing this today.</div><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><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">e.g.</div><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><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">protocol A {}</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">protocol B {}</div><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><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">typealias C = protocol<A, B></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">typealias D = protocol<B, A></div><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><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">print(C) // prints protocol<A, B></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">print(D) // prints protocol<A, B></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">print(C.self == D.self) // prints true</div><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><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Basically what I mean</div><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><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Any<SomeProtocol, class, AnotherProtocol></div><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><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Any<Any<ProtocolA, ProtocolB>, UIView></div><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><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">should be valid.</div> <br> <div id="bloop_sign_1463589932898822144" 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 18. Mai 2016 bei 18:30:02, Austin Zheng 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>
I made heavy revisions to my proposal to reflect all the great
feedback I got from you and several other folks (<a href="https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md" class="">https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md</a>).
<div class=""><br class=""></div>
<div class="">Here are a couple of thoughts:</div>
<div class=""><br class=""></div>
<div class="">- I used 'requirements' because that's how the
grammar describes similar constructs elsewhere in Swift. Open to
change, though.</div>
<div class=""><br class=""></div>
<div class="">- Having only one where clause makes complete sense.
Protocol extensions and generics all use one where clause, so
should this construct.</div>
<div class=""><br class=""></div>
<div class="">- The "P can be used in lieu of Any<P>" just
means you can declare e.g. "x : Equatable" if you want, instead of
"x : Any<Equatable>", just like you can with protocols
without associated types or self requirements today.</div>
<div class=""><br class=""></div>
<div class="">- I've come to the conclusion that it's probably best
to propose the proposal in the most general form, and allow any
reviewers on the core team to excise parts they don't think are
useful enough or are too difficult to implement. In that spirit,
the 'simple Any<...>' construct is gone and Any usage is
fully general.</div>
<div class=""><br class=""></div>
<div class="">- I moved discussion of typealiases back into the
main protocol, like you said, because typealiases using
existentials are *not* actually generic and can be done
today.</div>
<div class=""><br class=""></div>
<div class="">- I added some stuff about 'narrowing' existentials
at point of use using as?. This isn't part of 'opening
existentials' and should fit in this proposal nicely.</div>
<div class=""><br class=""></div>
<div class="">- I want a type expert to look at the 'usage'
section, but I'm reasonably sure there's not much more flexibility
we can give the user. Parameter associated types can't be treated
as covariant (they are almost always invariant or contravariant
IIRC) and therefore they should only be accessible if fully bound.
Return types can be treated as covariant; some languages do and
some don't. (Swift falls into the second bucket.) I would love to
be wrong, though.</div>
<div class=""><br class=""></div>
<div class="">Austin</div>
<div class="">
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On May 18, 2016, at 8:45 AM, Matthew Johnson
<<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="auto" class="">
<div class=""></div>
<div class="">
<div class=""></div>
<div class="">
<div class=""><br class="">
<br class="">
Sent from my iPad</div>
<div class=""><br class="">
On May 18, 2016, at 2:35 AM, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>> wrote:<br class="">
<br class=""></div>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">I've put together a considerably more
detailed draft proposal, taking into account as much of Matthew's
feedback as I could. You can find it below:
<div class=""><br class=""></div>
<div class=""><a href="https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md" class="">https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md</a><br class="">
</div>
<div class=""><br class=""></div>
<div class="">Since there is no chance this will come up for review
anytime soon, I expect to make significant revisions to it over the
next month or so. Any feedback would be greatly appreciated.</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">Thank you for working on this! Great
progress.</div>
<div class=""><br class=""></div>
Minor nit, but I think the proper word is constraint rather than
requirement here:
<div class=""><br class=""></div>
<div class="">"<span style="background-color: rgba(255, 255, 255, 0);" class="">Within the
angle brackets <code style="box-sizing: border-box; padding: 0.2em 0px; margin: 0px; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class=""><</code> and <code style="box-sizing: border-box; padding: 0.2em 0px; margin: 0px; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">></code> are zero or more <em style="box-sizing: border-box;" class="">requirements</em>. Requirements
are separated by commas."</span></div>
<div class=""><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; -webkit-text-size-adjust: 100%; background-color: rgb(255, 255, 255);" class=""><br class=""></span></div>
<div class=""><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; -webkit-text-size-adjust: 100%; background-color: rgb(255, 255, 255);" class="">Another tweak: </span></div>
<div class=""><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; -webkit-text-size-adjust: 100%; background-color: rgb(255, 255, 255);" class=""><br class=""></span></div>
<div class=""><font face="UICTFontTextStyleTallBody" class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><code style="box-sizing: border-box; padding: 0.2em 0px; margin: 0px; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">"P </code>can be used in lieu of <code style="box-sizing: border-box; padding: 0.2em 0px; margin: 0px; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">Any<P></code>, where <code style="box-sizing: border-box; padding: 0.2em 0px; margin: 0px; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">P</code> is a protocol with or without associated
type or self requirements."</span></font></div>
<div class=""><font face="UICTFontTextStyleTallBody" class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></font></div>
<div class=""><font face="UICTFontTextStyleTallBody" class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">This proposal is introducing generalized
existentials.</span></font> <span style="background-color: rgba(255, 255, 255, 0);" class=""> P and
Any<P> should be interchangeable for any protocol regardless
of requirements of the protocol. Existentials of protocols
with self or associated type requirements that do not include
constraints will just expose limited direct functionality. It
would still be possible to attempt cast them to concrete types to
recover more functionality. In the future (after a follow on
proposal) it will also be possible to open the
existential.</span></div>
<div class=""><br class=""></div>
<div class="">Thorsten pointed out that there should only be one
where clause for the whole existential. This follows the
structure of generic type and function constraints. It may
also be worth removing the 'as' alias from this proposal.
This could be introduced as a stand alone proposal where it
would apply to any context with generic constraints.</div>
<div class=""><br class=""></div>
<div class="">Another item:</div>
<div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">// NOT ALLOWED
let a : Any<Any<ProtocolA, ProtocolB>></span></div>
<div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div>
<div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Why is this
not allowed? It is pointless, but should be allowed and
considered identical to the flattened syntax.</span></div>
<div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div>
<div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">On dynamic
casting, I don't believe it should be restricted in the way you
have defined here. Casting *to* an existential doesn't have
anything to do with opening an existential. We should allow
casting to any existential type. </span></div>
<div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div>
<div class="">On a similar note, I completely disagree with the
limitation you specify for use of Any in generic constraints
precisely because of your counterargument. In the discussion
about moving the where clause it has been noted that sometime it is
necessary to apply a lot of constraints to get the necessary
effect. A mechanism for factoring constraints is highly
desirable and will greatly improve the readability of generic code.
Typealiases bound to Any can provide such a mechanism.
Let's not artificially restrict the use of it.</div>
<div class=""><br class=""></div>
<div class="">The section regarding members of a partly constrained
existential needs to be more fleshed out. We can't simply
punt it to a future proposal. However, I do think it is a
good idea to wait until the core team has time to participate in
the discussion.</div>
<div class=""><br class=""></div>
<div class="">The section about defining typealias also should not
be left to the future. It is possible to define typealias
with protocol<> today and to use that alias in a generic
constraint. Removing that capability would be a regression.
In fact, it's utility will increase significantly with this
proposal.</div>
<div class=""><br class=""></div>
<div class="">In general, I don't think we need the distinction
between simple and full Any. The whole idea of this proposal
IMO should be fully generalizing existentials. If
restrictions are necessary they should be due to (hopefully
temporary) implementation considerations.</div>
<div class=""><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 Tue, May 17, 2016 at 9:52 PM, Austin
Zheng <span dir="ltr" class=""><<a href="mailto:austinzheng@gmail.com" target="_blank" class="">austinzheng@gmail.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 dir="ltr" class=""><br class="">
<div class="gmail_extra"><br class="">
<div class="gmail_quote"><span class="">On Tue, May 17, 2016 at
1:25 PM, Matthew Johnson <span dir="ltr" class=""><<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>></span> wrote:</span>
<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="">
<div class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""><span class=""> </span></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class=""><span class=""><span class=""><br class=""></span></span>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">Within the angle brackets are zero or
more 'clauses'. Clauses are separated by semicolons. (This is so
commas can be used in where constraints, below. Better ideas are
welcome. Maybe it's not necessary; we can use commas
exclusively.)</span></div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><span class=""><br class=""></span></div>
<div class="">I’m not a fan of the semicolon idea. I don’t
see any reason for this. The `where` keyword separates the
protocol list from the constraints just fine. The list on
either side should be able to use commas with no problem (or line
breaks if that proposal goes through).</div>
<span class=""><br class=""></span></div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">I'm leaning towards getting rid of the commas, but
would like to write out a few 'dummy' examples to see if there are
any readability issues that arise. <br class=""></div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">Replaced with what? Whitespace
separation? I suppose that might work for the protocol list
but it feels inconsistent with the rest of Swift. Commas plus
(hopefully) the alternative of newline seem like the right
direction to me.</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">Sorry, I completely misspoke (mistyped?). I meant I
want to get rid of the semicolons and use commas. I've come to the
conclusion that there are no readability issues, protocol<>
already uses commas, and semicolons used in this manner don't have
a precedent anywhere else in the language.</div>
<div class=""><span class=""> </span></div>
<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="">
<div class=""><span class=""><span class=""><br class=""></span></span>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">There are five different possible
clauses:</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class="">
<ul class="">
<li class=""><span class="">'class'. Must be the first clause, if
present. Places a constraint on the existential to be any class
type. (Implies: Only one can exist. Mutually exclusive with class
name clause.)<br class=""></span></li>
</ul>
</div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">(In the future a follow-up proposal
should add in 'struct' or 'value' as a counterpart.)</span></div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><span class=""><br class=""></span></div>
<div class="">If we’re going to allow `struct` we should also allow
`enum`. `value` would allow either of those.</div>
<span class=""><br class=""></span></div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">Of course. A future proposal can allow list members
to discuss the exact details as to how struct, value, or enum
specifiers should work. <br class=""></div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">Yep, agree. Just mentioning that if we’re going
to reference it we should not leave obvious holes in what would be
considered. :)</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">Absolutely.</div>
<div class=""><span class=""> </span></div>
<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="">
<div class=""><span class=""><span class=""><br class=""></span></span>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">
<div class=""><span class=""><br class=""></span></div>
<div class="">
<ul class="">
<li class=""><span class="">Class name. Must be the first clause,
if present. (Implies: Only one can exist. Mutually exclusive with
'class'.) Places a constraint on the existential (not really an
existential anymore) to be an instance of the class, or one of its
subclasses.<br class=""></span></li>
</ul>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class="">It is still be an existential if it includes protocol
requirements that the class does not fulfill. For example,
you might have Any<UIView, SomeProtocol> where UIView does
not conform to SomeProtocol, but various subclasses do.</div>
<div class=""><br class=""></div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">Fair enough. (I don't think the way things work would
be affected.)</div>
<div class=""> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class="">
<div class=""></div>
<div class="">Your proposal doesn’t discuss composing Any in the
way that Adrian’s did like this:</div>
<div class=""><br class=""></div>
<div class="">typealias Foo = Any<SomeClass, SomeProtocol,
OtherProtocol></div>
<div class="">Any<AnotherProtocol, Foo></div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">I didn't think it needed to be discussed. An
Any<...> existential type is a type 'expression' just like
any other, and should be allowed to participate in other
Any<...>s.</div>
</div>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class="">
<div class=""><br class=""></div>
<div class="">I like the idea of composition as it allows us to
factor out constraints. If we are going to do that we should
allow a class to be specified in the composition as long is it is a
subclass of all class requirements of Any types it composes.
For example, this should be allowed:</div>
<div class=""><br class=""></div>
<div class="">typealias Bar = Any<SubclassOfSomeClass, Foo,
AnotherProtocol></div>
<div class=""><br class=""></div>
<div class="">This is still one class requirement for Bar, it just
refines the class requirement of Foo to be SubclassOfSomeClass
rather than just SomeClass.</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">This is a good point. There should be clarification
as to how special cases of Any<...> used in another
Any<...> behave. For example, like you said Any<MyClass,
Any<SomeSubclassOfMyClass, Protocol>> should be valid.
This will go into any proposal that emerges from the
discussion.</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">Yes, this is why we need to discuss Any
composition. There are also cases of incompatible associated
type constraints which need to be rejected (such as composing two
Any’s where one has Element == String and another has Element ==
Int).</div>
</div>
</div>
</blockquote>
<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="">
<div class=""><span class=""><br class=""></span>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""><span class=""> </span></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class=""><span class=""><span class=""><br class=""></span></span>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">
<div class=""><span class="">Example: Any<UIViewController;
UITableViewDataSource; UITableViewDelegate></span></div>
<div class=""><span class="">"Any UIViewController or subclass
which also satisfies the table view data source and delegate
protocols"</span></div>
<div class="">
<ul class="">
<li class=""><span class="">Dynamic protocol. This is entirely
composed of the name of a protocol which has no associated types or
Self requirement.</span></li>
</ul>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">
<div class=""><span class="">Example:
Any<CustomStringConvertible; BooleanType></span></div>
<div class=""><span class="">"Any type which conforms to both the
CustomStringConvertible and BooleanType protocols"</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">I'm going to use 'static protocol' to
refer to a protocol with associated types or self requirements.
Feel free to propose a more sound name.</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class="">
<ul class="">
<li class=""><span class="">Self-contained static protocol, simple.
This is composed of the name of a static protocol, optionally
followed by a 'where' clause in which the associated types can be
constrained (with any of the three basic conformance types:
subclassing, protocol conformance, or type equality). Associated
types are referred to with a leading dot.<br class=""></span></li>
</ul>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class="">Please do not introduce terms “dynamic protocol” and
“static protocol”. We want to support existentials of
protocols that have self or associated type requirements. The
dynamic vs static distinction is a limitation of the current
implementation of Swift and doesn’t make sense for the long term
vision.</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">I'm not trying to introduce new terms, these are just
placeholders. At the same time "protocols with self or associated
type requirements" is cumbersome to work with and it would be nice
for someone to come up with a descriptive term of art for referring
to them.</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">I agree that a better term would be useful. In
the meantime, I would prefer something like “trivial” and
“nontrivial” protocols.</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">I've decided to just use the full name until the
community comes up with better names. Clarity is preferable to
brevity in this case.</div>
<div class=""><span class=""> </span></div>
<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="">
<div class=""><span class=""><span class=""><br class=""></span></span>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""><span class=""> </span></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class=""><span class=""><br class=""></span>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">Example: Any<Collection where
.Generator.Element : NSObject, .Generator.Element :
SomeProtocol></span></div>
<div class="">"Any type that is a Collection, whose elements are
NSObjects or their subclasses conforming to SomeProtocol.”</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">Swift does not allow disjunction of
requirements. Only conjunctions are supported. That
means the correct reading is:</div>
<div class=""><br class=""></div>
<div class="">"Any type that is a Collection, whose elements are
NSObjects<span class=""> </span><b class="">and</b><span class=""> </span>their subclasses conforming
to SomeProtocol.”</div>
<br class=""></div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">Yes, that is what I meant. "whose elements are
(NSObjects or their subclasses) conforming to SomeProtocol”.</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">Ok, good. Wasn’t quite clear to me.</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">Yes, the verbiage will need to be clearer in the
future. That sentence could be ambiguously parsed.</div>
<div class=""><span class=""> </span></div>
<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="">
<div class=""><span class=""><span class=""><br class=""></span></span>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">
<div class=""><span class=""><br class=""></span></div>
<div class="">
<ul class="">
<li class=""><span class="">Bound static protocol. This is the same
as a self-contained static protocol, but with a leading
"<name> as " which binds the protocol to a generic typealias.
The name can be then be used in subsequent clauses to build
constraints.<br class=""></span></li>
</ul>
</div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">Example: Any<T as Collection;
IntegerLiteralConvertible where .IntegerLiteralType ==
T.Element>.</span></div>
<div class="">"Any type that is a Collection, and also can be built
from an integer literal, in which the collection elements are the
same type as the type of the integer used for the integer literal
conformance.”</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">I’m not sure about this, but if we’re going to do it
it should be the other way around: `Collection as T` with the
alias<span class=""> </span><i class="">after</i> the
name of the protocol. </div>
<div class=""><br class=""></div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">I like this, it flows better. "Protocol as T where
Protocol.Foo == Int, Protocol.Bar : Baz”.</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">Why did you introduce an alias here and then not use
it? Did you mean "Protocol as T where T.Foo == Int, T.Bar :
Baz"</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">Another result of rushing to compose an email.
Sorry!</div>
<div class=""><span class=""> </span></div>
<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="">
<div class=""><span class=""><span class=""><br class=""></span></span>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""><span class=""> </span></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class="">
<div class=""></div>
<div class=""><span class="">You are also using “dot shorthand”
here to refer to an associated type of
IntegerLiteralConvertible. I think “dot shorthand” should be
limited to cases where there is only one protocol that is getting
constrained. In other cases, we need to be clear about which
protocol we are referring to.</span></div>
</div>
</div>
</blockquote>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">I borrowed dot shorthand from the
generics manifesto. But you are right, it should only be allowed if
there is one protocol with associated types or self requirements
clause in the Any<...> construction.</span></div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><span class=""><br class=""></span></div>
<div class="">I would actually go further and limit it to one
protocol period, and possibly even to one protocol and no type
names (as types can have nested types and typealiases). When
we allow shorthand it should be immediately unambiguous what the
shorthand references with no need to look at type or protocol
declarations.</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">It might be desirable to propose the proposal with no
allowance for shorthand, and have the dot shorthand be a smaller
follow-up proposal.</div>
<div class=""><span class=""> </span></div>
<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="">
<div class=""><span class=""><span class=""><br class=""></span></span>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""><span class=""> </span></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class=""><span class=""><span class=""><br class=""></span></span>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">There will be rules to prevent
recursive nesting. For example, if generic typealiases are allowed,
they cannot refer to each other in a circular manner (like how
structs can't contain themeselves, and you can't create a cyclic
graph of enums containing themselves).</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">How an existential can be used depends
on what guarantees are provided by the clauses. For example,
'Any<Equatable>' can't be used for much; if there were any
methods on Equatable that did not use the associated types at all
you'd be able to call them, but that's about it. However,
'Any<Equatable where .Self == String>' would allow for == to
be called on instances. (This is a stupid example, since
Any<Equatable where .Self == String> is equivalent to
'String', but there are almost certainly useful examples one could
come up with.)</span></div>
</div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">In order of increasing
'power':</span></div>
<div class="">
<ul class="">
<li class=""><span class="">Don't constrain any associated types.
You can pass around Any<Equatable>s, but that's about
it.</span></li>
<li class=""><span class="">Constrain associated types to conform
to protocols.</span></li>
<li class=""><span class="">Fully constrain associated
types.</span></li>
</ul>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<div class="">I think we need to spell out pretty clearly what
members we expect to be available or not available. This
section probably needs the most design and elaboration.
</div>
<div class=""><br class=""></div>
<div class="">For example, we probably can’t access a member who
uses an associated type as an input unless it is constrained to a
specific type. On the other hand output types probably don’t
need to limit access to a member. However, if the output type
is Self or an associated type the visible signature would have an
output type which has the relevant constraints of the existential
applied, but no more. In some cases this means the output
type would simply be Any.</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">Absolutely. This is vaguely what I had in mind but I
wanted to get something down first. Thanks for thinking through
some of the implications :).</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">That’s what I thought. Just wanted to start the
process of elaborating expectations.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""><span class=""> </span></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">Where this really gets tricky is for
compound types like functions, generic types, etc. Working
out the details in these cases is pretty complex. I will
defer to Doug on whether it is best to just defer those cases to
the future, leave them up to the implementer, or try to work out
all of the relevant details in the proposal (in which case we
probably need a type system expert to help!).</span></div>
</div>
</blockquote>
<div class=""><span class=""><br class=""></span></div>
<div class="">Yes, exactly! For example, can Any<...>
existentials involving protocols with associated types or self
requirements be used within generic function or type definitions?
Maybe there's an argument that existential types of this nature are
redundant if you have access to generics (e.g. defining a property
on a generic type that is a Collection containing Ints; you should
be able to do that today). On the other hand, maybe there are use
cases I haven't thought of…</div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">I see no reason they shouldn’t be. They are not
redundant at all. For example, you may want to store
instances in a heterogeneous collection. You need
existentials to do that.</div>
<div class=""><br class=""></div>
<div class="">A simple example of what I was referring to there is
something like this:</div>
<div class=""><br class=""></div>
<div class="">protocol P {</div>
<div class=""> associatedtype Foo</div>
<div class=""><br class=""></div>
<div class=""> func bar(callback: (Foo) ->
())</div>
<div class="">}</div>
<div class=""><br class=""></div>
<div class="">In other words, types in the signature of a protocol
member are complex types that reference Self or associated
types. I think you really need a formal understanding of the
type system to understand how to expose these members through a
constrained existential. We can probably understand the
expected behavior in some of the simpler cases on a case by case
basis, but that approach doesn’t scale at all and is
arbitrary. If they’re going to be supported an expert is
going to need to be involved in the design.</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">Yes. I have some ideas regarding this topic.</div>
<div class=""><span class=""> </span></div>
<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="">
<div class=""><span class=""><span class=""><br class=""></span></span>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""><span class=""> </span></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">One area you didn’t touch on is
“opening” the existential? Is that out of scope for this
proposal? That would be fine with me as this proposal is
already taking on a lot. But if so, you should mention
something about future directions as it is pretty closely related
to this proposal.</span></div>
</div>
</blockquote>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">Yes, existential opening is explicitly
separate from this (although I wanted to mention it in the section
where I talk about how Any<Equatable> is not very useful).
But you are absolutely right, this proposal should discuss how it
wants to interact with possible future directions.</span></div>
</div>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""><span class=""> </span></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">Another area you didn’t touch on is
whether Any constructs (and typealiases referring to them) should
be usable as generic constraints. I would expect this to be
possible but I think we need to spell it out.</span></div>
</div>
</blockquote>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">I'm hoping for community input. This
is a tricky subject, and at some point we'll bump into
implementation limitations.</span></div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><span class=""><br class=""></span></div>
<div class="">I don’t think it’s too tricky. You can just
unpack the constraints of the Any into the list of generic
constraints. Maybe I’m missing something, but I don’t think
so.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class=""><span class=""><font color="#888888" class=""><br class=""></font></span></div>
<div class=""><span class=""><font color="#888888" class="">-Matthew</font></span></div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class=""></div>
</blockquote>
</div>
<br class=""></div>
</div>
</blockquote>
</div>
<br class=""></div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class=""></div>
</div>
_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></body></html>