<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>In his message Chris stated that protocols are obviously dynamic while in the case of protocol extensions we have default implementations (IMHO out of place in protocols if we see protocols are pure abstract contracts designed to decouple from the actual implementation) and the compiler will use a static implementation just because of the dressing/the type our object is casted as. It just feels wrong and an indication that we are now leaking implementation details we were trying to hide.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I think this is a compiler optimisation which should not be implicitly applied unless it has side effects and this example shows one of those side effects. In such cases, I think we should have a keyword to override the compiler with and strongly hint we want to enforce the compiler to use the static implementation.</div><div id="AppleMailSignature"><br>Sent from my iPhone</div><div><br>On 4 Jan 2016, at 02:52, Drew Crawford via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">I offer a +1, but I have two criticisms of the proposal.<div class=""><br class=""></div><div class="">The first is that the example given in the proposal is stated a lot more strongly than is true:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="highlight highlight-source-swift" style="box-sizing: border-box; margin-bottom: 16px; 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);"><pre style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; margin-top: 0px; margin-bottom: 0px; line-height: 1.45; padding: 16px; background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-wrap: normal; word-break: normal;" class=""><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">func</span> <span class="pl-en" style="box-sizing: border-box; color: rgb(121, 93, 163);">compareTwo</span>(first: <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Comparable</span>, _ <span class="pl-smi" style="box-sizing: border-box;">second</span>: <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Comparable</span>) <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">-></span> <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Int</span> { <span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// error!</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">if</span> first <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);"><</span> second {
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">return</span> <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">-1</span>
}
<span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">//...</span>
}</pre></div><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; 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);" class="">The code above yields an error, and rightfully so, because if the real types of first and second are not equal, they cannot actually be compared.</p></blockquote><div class="">It is true for Swift 2 code. However, whether this is true forever is less clear. There is a thread here discussing "existential protocols", which AFAIK would make this code listing into a non-error, and in that thread Douglas Gregor said:</div><div class=""><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class="">Do recall that I’m saying “not now” rather than “not ever” for this feature. I think it’s very, very cool, but it’s complicated and we need a while to understand its overall effects.</div></blockquote><div class=""><br class=""></div><div class="">As long as the door is open to allowing the syntax, I think saying something strong and normative about it in an official proposal would be a mistake. The example is fine, but the comment should be that this "currently errors" or "surprises new programmers" or something weaker than "it's obvious to all of us this shouldn't work" because it's obvious to some people that it should work after all.</div><div class=""><br class=""></div><div class="">The second thing is that I think using the words "dynamically dispatched" or "dynamically dispatched interfaces" in the body of the proposal is a mistake. It is not that interfaces "<b class="">are</b>" dynamically dispatched. It is that they <b class="">may be</b>, e.g. that the compiler may select a dynamic implementation (<b class="">or it may be able to find a static implementation</b>), whereas for a protocol the compiler is <b class="">guaranteed</b> to use a static implementation. This is I think more consistent with <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001948.html" class="">CL's position on static/dynamic in Swift</a> generally. So I think we should find a turn of phrase like "behaves dynamically" or "has dynamic dispatch semantics" rather than saying "it *is* dynamically dispatched" as if we will force the optimizer to spit out a vtable when it can find a static implementation.</div><div class=""><br class=""></div><div class="">With those two details resolved I think it is a strong proposal, and very much in line with the proposal we're reviewing about separating typealias vs associatedtype, which strikes at a similar confusion where we're separating two different concepts into their own keywords.</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 3, 2016, at 7:44 PM, Austin Zheng 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 dir="ltr" style="font-family: HelveticaNeue; font-size: 12px; 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="">+1 to "opening" values of existential type, I remember trying (and failing) to do this when Swift 1 came out. Being able to capture the dynamic type of an object at runtime and do stuff with it would be incredible.<div class=""><br class=""></div><div class="">Austin</div></div><div class="gmail_extra" style="font-family: HelveticaNeue; font-size: 12px; 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;"><br class=""><div class="gmail_quote">On Sun, Jan 3, 2016 at 4:19 PM, David Waite via swift-evolution<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</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 style="word-wrap: break-word;" class=""><div class="">This would be wonderful - is it something that could happen in the Swift 3 timeframe? Is it something that myself or someone else could work on a formal proposal for?</div><div class=""><br class=""></div><div class="">-DW</div><br class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="h5"><div class="">On Jan 3, 2016, at 4:17 PM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""></div></div><div class=""><div class=""><div class="h5"><div dir="auto" class=""><div class=""><span class=""></span></div><div class=""><br class=""><div style="direction: ltr;" class=""><blockquote type="cite" class=""><div class="">On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div style="font-size: 12.8px;" class="">Introduction of interfaces will clean up the current blend of static and dynamic protocols, and solve at least three popular issues.</div><div style="font-size: 12.8px;" class="">Please see:</div><div style="font-size: 12.8px;" class=""><a href="https://github.com/Anton3/swift-evolution/blob/master/proposals/0000-introducing-interfaces.md" target="_blank" class="">https://github.com/Anton3/swift-evolution/blob/master/proposals/0000-introducing-interfaces.md</a></div></div></div></blockquote><div style="direction: ltr;" class=""><br class=""></div>I am *completely* against this proposal.</div><div style="direction: ltr;" class=""><br class=""></div><div style="direction: ltr;" class="">Fundamentally, you're trying to address the limitation that protocols with Self or associated type requirements can't be existential. But it's just a limitation that isn't (conceptually) that hard to fix: the primary operation you need to work with an existing of such a protocol is to "open" a value of existential type, giving a name to the dynamic type it stores. Let's invent one:</div><div style="direction: ltr;" class=""><br class=""></div><div style="direction: ltr;" class=""> <span class="Apple-converted-space"> </span>func eq(x: Equatable, y: Equatable) -> Bool {</div><div style="direction: ltr;" class=""> <span class="Apple-converted-space"> </span>// give the name T to the dynamic type stored in xT</div><div style="direction: ltr;" class=""> <span class="Apple-converted-space"> </span>let xT = open x as T</div><div style="direction: ltr;" class=""> <span class="Apple-converted-space"> </span>// is y also storing a T?</div><div style="direction: ltr;" class=""> <span class="Apple-converted-space"> </span>guard let yT = y as? T else { return false }</div><div style="direction: ltr;" class=""> <span class="Apple-converted-space"> </span>// check whether the Ts are equal</div><div style="direction: ltr;" class=""> <span class="Apple-converted-space"> </span>return xT == yT</div><div style="direction: ltr;" class=""> <span class="Apple-converted-space"> </span>}</div><div style="direction: ltr;" class=""><br class=""></div><div style="direction: ltr;" class="">Ignore the syntax: semantically, we've gone from a "dynamic" existential thing back to something more "static", just by giving a name to the type. Swift generics aren't really even static in any sense: what the do is give names to the types of values so one can establish relationships among different values. "open..as" would do that for existentials. </div><div style="direction: ltr;" class=""><br class=""></div><div style="direction: ltr;" class="">Note that ether Swift compilers AST and SIL both have "open existential" operations that do this internally. They have no spelling in Swift code, but they are useful to describe operations on existentials. At present, they cannot be formed when the existential involves a protocol with Self or associated type requirements, but that's a limitation that isn't hard to address. </div><div style="direction: ltr;" class=""><br class=""></div><div style="direction: ltr;" class="">As for your concerns about knowing when one can dynamically override and when one cannot... There are issues here that need to be addressed. They aren't significant enough to warrant such a drastic change, and may not even require language changes at all. </div><div style="direction: ltr;" class=""><br class=""></div><div style="direction: ltr;" class=""><span style="white-space: pre-wrap;" class=""> </span>- Doug</div><div style="direction: ltr;" class=""><br class=""></div><div style="direction: ltr;" class=""><br class=""></div></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=nE9rxSXA5G4kxsTVkgv43vFcOQoCM-2FU-2BigXPSqPoICLQMF0Is2N1gVcYyd8LXauWU01V8ADskXgeA1dZAXS87kb5mrtSnua8ix3PvTqk8IjbkCFnioGdyq-2BKvhwvXwvyetVprM5QJNhgoafyPtUnsoK0Jd9PVrhUVERURHcV29O9ap7P5ZtW-2FOxTbxXomN8xjYwI10z8Hb2x7y5-2BqncZc5sWcNEbG-2B6FFuGHrYPzWeE-3D" alt="" width="1" height="1" border="0" style="min-height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class=""></div></div></div><span class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></span></div></blockquote></div><br class=""><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=7XtDdMHRjqIUi4tzSjSp2pWQIyxYdP6woIWn4vwV5gcqFr4r03Dh8eKogFpiDvey1PIPaqe7zBTWkGgzjr7woVXbaxXCaffQPyqbNaWrCT31DHMqDKbDyZXdXLG0uJnEExUVUN9oEhXVqTbecWfsT7Rc3IiNpSEkALkUkC9ps1q0uigaGtwHxjKWfy7jae9C3Wddeg44wsab4HqrarOmVSVje8zK97AHm-2FldU6Lkrf0-3D" alt="" width="1" height="1" border="0" style="min-height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class=""></div><br class="">_______________________________________________<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" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""><br class=""></blockquote></div><br class=""></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=OtwgWwWn2mvmck2XIGZZg64wEmoo4f4ILYe4SqMqwHrnq0ueUAPZC4C87LsFpgfO-2FhklSONSBL4YzfqjouWHhfoWfwDbM-2B4LOk-2FdVFY0J-2FCTAcHldkfn37HlIC-2FZgV-2Fi5jxuDtM4Xws1kl8T7AwtiumKOkKQmd-2ByBs2cfB0LAHSHM3UckNcjCeqo7v3KRGNuhGh4d-2F-2Buk-2B8rjLHFCGEZZzJCC4RsWAHaUMDzlY15eO8-3D" alt="" width="1" height="1" border="0" style="font-family: HelveticaNeue; font-size: 12px; 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; height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class=""><span style="font-family: HelveticaNeue; font-size: 12px; 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 class="Apple-converted-space"> </span>_______________________________________________</span><br style="font-family: HelveticaNeue; font-size: 12px; 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: HelveticaNeue; font-size: 12px; 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: HelveticaNeue; font-size: 12px; 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: HelveticaNeue; font-size: 12px; 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: HelveticaNeue; font-size: 12px; 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: HelveticaNeue; font-size: 12px; 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=""></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=dXNHRXbGTqqssqDI7Hn7KyogJzdRthQdFNkQ7LxhQVNu4jD1C88vnFiHroeFb1vPNoqjEl1ROze9gyfE06odyIDV5sjlnELlGoELo3sNKWbtXeyWx-2BfCFPhcczR7DIS4JGz-2BdAvL6Ai7wj6bN0nNh0HqWjly5gxCrcYUy3gSVBrPvY2ICjqUBZsDd-2BcYBkL-2Bc0Z3vDtX72uujX2vixay4yk5jqHEnVjAJ4TLZw2KIz8-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>