<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 28, 2016 at 6:44 PM, Erica Sadun <span dir="ltr"><<a href="mailto:erica@ericasadun.com" target="_blank">erica@ericasadun.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>Can you give me a specific example of where this approach fails for you?</div><span class=""><font color="#888888"><div><br></div><div>-- E</div></font></span></div></blockquote><div><br></div><div><br></div><div>Sure, I'll describe one (renaming some things for clarity and stripping out the meat of the code, because it's not relevant and because it's not elegant)--</div><div><br></div><div>In one file, I have:</div><div><br></div><div>```</div><div>class PortedTransfom {</div><div>// this class was ported from C++</div><div>// it transforms input FP values to output values in a complicated way</div><div>// it's a standalone entity and the algorithm is even under patent</div><div>// (not owned by me, though it's legal for me to use it for my purposes)</div><div>// for this reason, this ported code lives in its own file</div><div>}</div><div>```</div><div><br></div><div>In another file, I have:</div><div><br></div><div>```</div><div>class MyAsinhTransform {</div><div>// this class was written by me</div><div>// nothing earth-shattering here</div><div>}</div><div><br></div><div>class MyLogTransform {</div><div>// also written by me</div><div>}</div><div><br></div><div>class MyLinearTransform {</div><div>// also written by me</div><div>}</div><div>```</div><div><br></div><div>Transforming values one-at-a-time isn't fast enough, so in another file, I have:</div><div><br></div><div>```</div><div>import Accelerate</div><div><br></div><div>protocol AcceleratedTransform {</div><div> func scale(_: [Double]) -> [Double]</div><div> func unscale(_: [Double]) -> [Double]</div><div>// other functions here</div><div>// some are already implemented in PortedTransform, though</div><div>}</div><div>extension AcceleratedTransform {</div><div>// default implementations for some functions</div><div>// but not `scale(_:)` and `unscale(_:)`, obviously</div><div>}</div><div><br></div><div>extension MyAsinhTransform : AcceleratedTransform {</div><div>// use BLAS to implement scale(_:) and unscale(_:)</div><div>// and override some default implementations<br></div><div>}</div><div><br></div><div>extension MyLogTransform : AcceleratedTransform {</div><div>// use BLAS to implement scale(_:) and unscale(_:)</div><div>// and override some default implementations<br></div><div>}<br></div><div><br></div><div>extension MyLinearTransform : AcceleratedTransform {</div><div><div>// use BLAS to implement scale(_:) and unscale(_:)</div><div>// and override some default implementations<br></div><div>}<br></div></div><div><br></div><div>extension PortedTransform : AcceleratedTransform {</div><div>// use BLAS to implement scale(_:) and unscale(_:)</div><div>}</div><div>```</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><div><blockquote type="cite"><div>On Apr 28, 2016, at 5:24 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr"><div>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><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 28, 2016 at 6:09 PM, Howard Lovatt via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);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><div><br><br>On Friday, 29 April 2016, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br><br>Sent from my iPad</div><div><br>On Apr 28, 2016, at 5:49 PM, Erica Sadun <<a>erica@ericasadun.com</a>> wrote:<br><br></div><blockquote type="cite"><div><br><div><blockquote type="cite"><div>On Apr 28, 2016, at 12:18 PM, Matthew Johnson <<a>matthew@anandabits.com</a>> wrote:</div><div><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">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><div>These are compile-time checks and should not affect compiled code.</div></div></blockquote><div><br></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><br><blockquote type="cite"><div><div><br></div><div>-- E</div><div><br></div></div></blockquote></div></div></blockquote><br><br></div></div><span><font color="#888888">-- <br>-- Howard.<br>
</font></span><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div>