<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 18, 2016, at 12:12 PM, Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class="">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; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class=""><span style="font-family: Helvetica, Arial; font-size: 13px;" class="">One quick question: Do we really need this<span class="Apple-converted-space"> </span></span><font face="Helvetica" class="">"<span style="color: rgb(51, 51, 51);" class="">This must be the first requirement, if present.</span>“?</font></div></div></blockquote><div><br class=""></div><div>I’m on the fence about this. The reason it would matter is for readability. The counter argument to that is that you can’t rely on the first argument being a class to determine whether a composed Any will have a class constraint or not.</div><br class=""><blockquote type="cite" class=""><div class=""><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class="">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; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class="">e.g.</div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class="">protocol A {}</div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class="">protocol B {}</div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class="">typealias C = protocol<A, B></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class="">typealias D = protocol<B, A></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class="">print(C) // prints protocol<A, B></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class="">print(D) // prints protocol<A, B></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class="">print(C.self == D.self) // prints true</div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class="">Basically what I mean</div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class="">Any<SomeProtocol, class, AnotherProtocol></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class="">Any<Any<ProtocolA, ProtocolB>, UIView></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class="">should be valid.</div><br style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div id="bloop_sign_1463589932898822144" class="bloop_sign" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="font-family: helvetica, arial; font-size: 13px;" class="">-- <br class="">Adrian Zubarev<br class="">Sent with Airmail</div></div><br style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><p class="airmail_on" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Am 18. Mai 2016 bei 18:30:02, Austin Zheng via swift-evolution (<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>) schrieb:</p><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""></div><div class="">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 class=""><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 class="" style="background-color: rgba(255, 255, 255, 0);">Within the angle brackets <code class="" 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;"><</code> and <code class="" 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;">></code> are zero or more <em class="" style="box-sizing: border-box;">requirements</em>. Requirements are separated by commas."</span></div><div class=""><span class="" 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; background-color: rgb(255, 255, 255);"><br class=""></span></div><div class=""><span class="" 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; background-color: rgb(255, 255, 255);">Another tweak: </span></div><div class=""><span class="" 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; background-color: rgb(255, 255, 255);"><br class=""></span></div><div class=""><font face="UICTFontTextStyleTallBody" class=""><span class="" style="background-color: rgba(255, 255, 255, 0);"><code class="" 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;">"P </code>can be used in lieu of <code class="" 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;">Any<P></code>, where <code class="" 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;">P</code> is a protocol with or without associated type or self requirements."</span></font></div><div class=""><font face="UICTFontTextStyleTallBody" class=""><span class="" style="background-color: rgba(255, 255, 255, 0);"><br class=""></span></font></div><div class=""><font face="UICTFontTextStyleTallBody" class=""><span class="" style="background-color: rgba(255, 255, 255, 0);">This proposal is introducing generalized existentials.</span></font><span class="Apple-converted-space"> </span><span class="" style="background-color: rgba(255, 255, 255, 0);"> 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 class="" style="background-color: rgba(255, 255, 255, 0);">// NOT ALLOWED let a : Any<Any<ProtocolA, ProtocolB>></span></div><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);"><br class=""></span></div><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);">Why is this not allowed? It is pointless, but should be allowed and considered identical to the flattened syntax.</span></div><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);"><br class=""></span></div><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);">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 class="" style="background-color: rgba(255, 255, 255, 0);"><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 class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:austinzheng@gmail.com" target="_blank" class="">austinzheng@gmail.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><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 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 class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>></span><span class="Apple-converted-space"> </span>wrote:</span><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 class="" style="word-wrap: break-word;"><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="" 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;"><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 class="" style="word-wrap: break-word;"><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: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><div class=""><span class=""><span class=""><br class=""></span></span><blockquote type="cite" class=""><div class=""><div dir="ltr" class="" 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;"><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 class="" style="word-wrap: break-word;"><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: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><div class=""><span class=""><span class=""><br class=""></span></span><blockquote type="cite" class=""><div class=""><div dir="ltr" class="" 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;"><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 class="" style="word-wrap: break-word;"><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 class="" style="word-wrap: break-word;"><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" class="" 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;"><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 class="" style="word-wrap: break-word;"><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: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><div class=""><span class=""><br class=""></span><blockquote type="cite" class=""><div class=""><div dir="ltr" class="" 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;"><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 class="" style="word-wrap: break-word;"><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: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><div class=""><span class=""><span class=""><br class=""></span></span><blockquote type="cite" class=""><div class=""><div dir="ltr" class="" 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;"><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 class="" style="word-wrap: break-word;"><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: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><div class=""><span class=""><span class=""><br class=""></span></span><blockquote type="cite" class=""><div class=""><div dir="ltr" class="" 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;"><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 class="" style="word-wrap: break-word;"><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: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><div class=""><span class=""><span class=""><br class=""></span></span><blockquote type="cite" class=""><div class=""><div dir="ltr" class="" 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;"><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 class="" style="word-wrap: break-word;"><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: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><div class=""><span class=""><span class=""><br class=""></span></span><blockquote type="cite" class=""><div class=""><div dir="ltr" class="" 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;"><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 class="" style="word-wrap: break-word;"><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" class="" 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;"><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 class="" style="word-wrap: break-word;"><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: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><div class=""><span class=""><span class=""><br class=""></span></span><blockquote type="cite" class=""><div class=""><div dir="ltr" class="" 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;"><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 class="" style="word-wrap: break-word;"><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" class="" 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;"><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 class="" style="word-wrap: break-word;"><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" class="" 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;"><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 class="" style="word-wrap: break-word;"><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 class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></span></blockquote><span style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:swift-evolution@swift.org" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">swift-evolution@swift.org</a><br style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></body></html>