<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 Jun 8, 2016, at 11:52 AM, Thorsten Seitz <<a href="mailto:tseitz42@icloud.com" class="">tseitz42@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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 class=""><br class="Apple-interchange-newline">Am 07.06.2016 um 07:55 schrieb LM <<a href="mailto:laurent.mihalkovic@gmail.com" class="">laurent.mihalkovic@gmail.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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="Apple-interchange-newline"><br class="">On Jun 7, 2016, at 7:14 AM, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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 class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 6, 2016, at 10:08 PM, Thorsten Seitz <<a href="mailto:tseitz42@icloud.com" class="">tseitz42@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class=""></div><div class=""><br class=""></div><div class=""><br class="">Am 06.06.2016 um 22:13 schrieb L Mihalkovic <<a href="mailto:laurent.mihalkovic@gmail.com" class="">laurent.mihalkovic@gmail.com</a>>:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 6, 2016, at 9:34 PM, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 6, 2016, at 12:12 PM, Thorsten Seitz <<a href="mailto:tseitz42@icloud.com" class="">tseitz42@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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="Apple-interchange-newline"><br class="">Am 06.06.2016 um 18:51 schrieb Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>>:<br class=""><br class=""></div><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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 class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 5, 2016, at 3:24 AM, L. Mihalkovic 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="auto" class=""><div class="">The issue is to decide on the applicability scope. Thinking 'my app/their stuff' is an illusion. To the compiler & runtime there is only code split into modules, some in source code and others as dylibs (.dll, .so, ...). Any extension based conditional refines a protocol everywhere. What's hard is to compute the complete effects of these changes predictably, reliably and fast. Because when we consider 'but look, i have a single small extension', the compiler&runtime must be ready to deal symetrically <span class="" style="background-color: rgba(255, 255, 255, 0);">with anything we throw at it. T</span>hey can't start building 15 different ways the compute the side effects based on many different scenarios because it will be un-ruly code, and too complex to try to explain to us what we will see.</div><div class="">The circular redefinitions case is one of the knightmares that hides in there... would mean having to assign priority to scopes, when there is no scopes yet. At the moment, the binary conformance table contains records for 3 types of conformances. First step would be to add a new type to match extension based conformance, and then record where it came from, and add some priority scheme to be able to navigate any conformance chain(remember that the pb grows everytime we decide 'oh cool, lets use a Padleft module rather than write my own 15 lines to do it - see the recent pb with nodejs). Not a simple task even with time, which they do not have now.</div><div class=""><br class=""></div><div class="">@core_team i know this is a coarse explanation, but hopefully at least in the right ballpark.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Roughly, yes. The specific problem regards answering the question “where must the runtime look to determine whether a given type X conforms to protocol P?”. Right now, the runtime conceptually needs to look:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>1) Into a list of known protocol conformances for the type X, and</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>2) If X is a class type, the list of known protocol conformances for the superclass of X (recursively)</div><div class=""><br class=""></div><div class="">If we add the ability for a protocol extension to add a conformance to another protocol, add to that:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>3) Into the list of protocol extensions of other protocols Q that provide conformance to P</div></div></div></blockquote><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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;">So, the difference is that in the case</span><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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=""><div class=""><div dir="auto" class=""><div class=""><div class=""><div class=""><font class=""><span class="" style="background-color: rgba(255, 255, 255, 0);">protocol P { ... }</span></font></div><div class=""><font class=""><span class="" style="background-color: rgba(255, 255, 255, 0);">protocol Q : P { ... }</span></font></div></div></div>struct X : Q {...}</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">X's list of known protocol conformances already contains Q and P, </div><div dir="auto" class="">whereas in the case</div><div dir="auto" class=""><br class=""></div><div dir="auto" class=""><div class=""><div class=""><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);">protocol P { ... }</span></div><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);">protocol Q { ... }</span></div></div></div><span class="" style="background-color: rgba(255, 255, 255, 0);">struct X : Q {...}</span></div><div dir="auto" class=""><span class="" style="background-color: rgba(255, 255, 255, 0);">extension Q : P</span></div><div dir="auto" class=""><span class="" style="background-color: rgba(255, 255, 255, 0);"><br class=""></span></div><div dir="auto" class="">X's list of known protocol conformances just contains Q and is not extended by P as a result of the extension?</div><div dir="auto" class="">Did I understand this right?</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Yes, that’s correct.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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 class=""><div class=""><div dir="auto" class="">Is that (not being able to extend the conformance lists of all types as a result of an extension) a restriction of having module boundaries?</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Effectively, yes: you can’t simply enumerate all of the cases because some other module might add a new types/protocol extensions/conformances. It has to be dynamically discoverable.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">yes… for each new module added to a known mix, the final conformances list can be completely different. </div></div></div></blockquote><div class=""><br class=""></div>But this is information known at compile time and does not have to be determined at runtime. <div class="">An extension should be only effective in the module in which it is defined and in modules using that module. All of these get to know the extension at compile time.</div></div></div></blockquote></div></div></blockquote><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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;">The idea of swift 3/4 is that the stdlib ABI should be stable enough that it will be in the system rather than embedded in each app. Which means that the conformance table must be runtime discoverable from the module exporting it (in a section of the text segment), and its final effects computed by the runtime when the module gets loaded (again coarse grained expl) by each binary using it. This also lets them define new module boundaries in the system that we can transitively inherit.</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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;">Baking the final conformance statically into the module would leave us wondering why our code might seem to be 'frozen' and not using newer system defined conformances.<span class="Apple-converted-space"> </span></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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="">Good argument. So that would mean that the analysis would have to be done at linking time. This (like doing it at runtime) does open a can of worms about ambiguity, though: what happens when the new system version of a library suddenly defines an extension that conflicts with an extension in our module? Seems like that such a change should be confined to the system module unless doing a recompile, so we are back to my suggestion of resolving extensions at compile time?</div></div></blockquote><div><br class=""></div><div>There isn’t likely to be a perfect answer here. Resolving extensions at compile time cuts of various opportunities for dynamic discovery (e.g., the standard library’s print() looking for various conformances) that I, personally, am not willing to give up. Load-time resolution introduces the possibility of ambiguities—which we will likely need to detect or resolve in some way.</div><div><br class=""></div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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="">-Thorsten</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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=""><br class=""></div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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 class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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;">Mind you... this may not be a stupid idea at all, as it might align better with the practice of linking against specific SDKs to get a predictable level of behavior. </div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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;">As for scope, my limited understanding of the loader is that there is no 'source' field in these conformance records that would allow the runtime to treat them hierarchically. </div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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 class=""><div class=""><div class=""><br class=""></div><div class="">That’s not the model that Swift uses today. You can discover protocol conformances introduce by modules—whether you knew about those modules at compile time (but at launch time you end up with newer versions) or whether those modules were unknown, you see the conformances. The standard library’s “print” facility depends on this behavior to find CustomStringConvertible conformances.</div><div class=""><br class=""></div><div class="">Yes, we could make it all statically determined, but IMO that’s not the direction that Swift has been going.</div><div class=""><br class=""></div><span class="Apple-tab-span" style="white-space: pre;"> </span>- Doug</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><br class=""></div><span class="Apple-tab-span" style="white-space: pre;"> </span>- Doug</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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 class=""><div class=""><div dir="auto" class=""><br class=""></div><div dir="auto" class="">-Thorsten </div><div dir="auto" class=""><br class=""></div></div></div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">That’s a fairly significant expansion, and for each of the protocol extensions in (3), we need to evaluate whether X conforms to the extended protocol Q (and any additional constraints placed on that protocol extension).</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- Doug</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class=""><br class=""></div>On Jun 5, 2016, at 9:49 AM, Thorsten Seitz via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Am 04.06.2016 um 23:18 schrieb Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hello Dan,<div class=""><br class=""></div><div class="">You'll be pleased to learn that conforming generic types conditionally to protocols is on the roadmap (and is one of the highest priority items for the versions of Swift following 3.0): <a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-" class="">https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-</a></div><div class=""><br class=""></div><div class="">However, it's unlikely that protocols will gain conditional conformance: <a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-via-protocol-extensions" class="">https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-via-protocol-extensions</a></div></div></div></blockquote><div class=""><br class=""></div>"However, similar to private conformances, it puts a major burden on the dynamic-casting runtime to chase down arbitrarily long and potentially cyclic chains of conformances, which makes efficient implementation nearly impossible.“</div><div class=""><br class=""></div><div class="">I’ve been wondering what the problem with the implementation is. I mean instead of using an extension the same conformance could have been declared beforehand, i.e. instead of</div><div class=""><br class=""></div><div class="">protocol P { func foo() }</div><div class="">protocol Q { func bar() }</div><div class="">extension Q : P { func foo() { bar() } }</div><div class=""><br class=""></div><div class="">we could have written the allowed</div><div class=""><br class=""></div><div class=""><div class="">protocol P { func foo() }</div><div class="">protocol Q : P { func foo() { bar() } }</div><div class=""><br class=""></div></div><div class="">with the exact same effect.</div><div class=""><br class=""></div><div class="">The only difference would be that the extension might have been in another module than Q. </div><div class="">Is having to cross module boundaries causing the cited problems? Would the same problems exist if in the second example Q would be defined in another module?</div><div class=""><br class=""></div><div class="">-Thorsten</div><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">That document originates from a mailing list post made some time ago, and is a decent overview as to what sorts of type system features the Swift core developers are interested in building.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Austin</div></div></div></blockquote></div></div></blockquote></div></div></blockquote></div></div></blockquote></div></div></div></blockquote></div></div></div></blockquote></div></div></blockquote></div></div></div></blockquote></div></div></blockquote></div></blockquote></div></blockquote></div><br class=""></body></html>