<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Can you give me a specific example of where this approach fails for you?</div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 28, 2016, at 5:24 PM, Xiaodi Wu 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" class=""><div class="">I'm not sure that I'm entirely happy with this distinction between already compiled types and ones that have not yet been compiled. It's a common Swift idiom to implement protocol requirements in extensions, which encourages a kind of modularity, if you will. Every so often (and maybe this isn't best practice), I incorporate third-party code into a project in source form and not as a compiled library (with attribution, and in compliance with the license, etc., obviously). Often these are little snippets, perhaps useful helper functions or types. The beauty of extensions is that I can extend these as necessary without touching the original code. The point is, here one would not be able to implement certain things in that way if this proposal is adopted. To say that the workaround is just editing the original code is deeply unsatisfying, because it would be equally valid to say that the same workaround applies to stripping out extensions altogether for non-imported types.</div><div class=""><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Apr 28, 2016 at 6:09 PM, Howard Lovatt via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It is a good idea to explicitly document the behaviour that this requirement for override is a compile time check only and does not mean that already compiled code has to be recompiled to allow a protocol to be retroactively fitted to an already compiled type.<div class="HOEnZb"><div class="h5"><br class=""><br class="">On Friday, 29 April 2016, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class=""><br class=""><br class="">Sent from my iPad</div><div class=""><br class="">On Apr 28, 2016, at 5:49 PM, Erica Sadun <<a class="">erica@ericasadun.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 28, 2016, at 12:18 PM, Matthew Johnson <<a class="">matthew@anandabits.com</a>> wrote:</div><div class=""><div style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">We can't add the keywords if the structs are defined in a module we import but don't own. We are only declaring the conformance retroactively. The ability to do this is a crucial aspect of generic programming. It isn't yet clear how your proposal handles retroactive modeling.</div></div></blockquote></div><br class=""><div class="">These are compile-time checks and should not affect compiled code.</div></div></blockquote><div class=""><br class=""></div>Does that mean the conformance declaration will be accepted by the compiler under your proposal? I would really like to see this called out explicitly in the proposal.<div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div></div></blockquote></div></div></blockquote><br class=""><br class=""></div></div><span class="HOEnZb"><font color="#888888" class="">-- <br class="">-- Howard.<br class="">
</font></span><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></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>