<div dir="ltr">Inline below.<div class="gmail_extra"><br><div class="gmail_quote">On 1 February 2016 at 07:53, Maximilian Hünenberger <span dir="ltr"><<a href="mailto:m.huenenberger@me.com" target="_blank">m.huenenberger@me.com</a>></span> wrote:<br><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="auto"><div></div><div>See inline</div><div><br>Am 31.01.2016 um 01:48 schrieb Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div>Proposal<div>=======</div>Allow protocols to define a default implementation, e.g.:<div><br></div><div> protocol Complex {</div><div> default var re: Double = 0</div><div> default var im: Double = 0</div><div> var mag: Double { return sqrt(re * re + im * im) }</div><div> // ...</div><div> }</div></div></blockquote><div><br></div><div>Shouldn't there be a "default" before "<span style="background-color:rgba(255,255,255,0)">var mag: Double ...</span>"?</div></div></blockquote><div><br></div><div>No. It gets translated into a protocol member and an extension to the protocol. In the proposal, if default was put infant of the line then it wouldn't appear in the protocol nor the extension, just in the default struct.</div><div><br></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 dir="auto"> Which gets translated to:<br><blockquote type="cite"><div><br></div><div> <font size="2"><span style="background-color:rgba(255,255,255,0)">protocol Complex {</span></font><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> var re: Double { get, set }</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> var im: Double { get, set }</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> var mag: Double { get }</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> // ...</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> }</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> extension Complex {</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> var mag: Double { return sqrt(re * re + im * im) }</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> // ...</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> }</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> struct _DefaultComplex: Complex { // Some private name</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> var re: Double = 0</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> var im: Double = 0</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> // ...</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> }</span></font></div><div><div><br></div><div>In use:</div><div><br></div><div> let complex = Complex()</div><div><br></div><div>Gets translated into:</div><div><br></div><div> let complex = _DefaultComplex()</div><div><br></div><div><br></div><div>Motivation</div><div>========</div><div> 1. You often have a default implementation for a protocol, much like a function argument might have a default value. Therefore this proposal adds convenience by saving boilerplate.</div><div> 2. It is difficult to name a protocol if there is a natural default implementation. For example the natural name for the protocol that all integral types inherited from is Integer, but that is also the natural name for the default implementation. This tension between protocol and default implementation name leads to strange naming conventions like IntegerType for the protocol; we already know it is a type (it is a protocol after all!). This is just a form of Hungarian notation; most people find Hungarian obfuscates the code rather than clarifying.</div></div><div><br></div><div><br></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">Details</span></font><div><font size="2"><span style="background-color:rgba(255,255,255,0)">=====<br></span></font><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> 1. Change protocols so that protocol methods are dynamically dispatched, when overridden in an extension.</span></font></div></div></div></div></blockquote><div><br></div><div>That should probably be a separate proposal to make the current one more incremental.</div></div></blockquote><div><br></div><div>Yes. There has been discussion of this in another thread. This proposal would build on the previous one and I should have just referenced that proposal.</div><div> </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 dir="auto"><br><blockquote type="cite"><div><div><div><div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> 2. Change protocols so that all implementations and overrides of a protocol method require the override keyword.</span></font></div></div></div></div></div></blockquote><div><br></div><div>I would definitely love to see something <b>like</b> an override keyword. Although there could be confusion with method overrides in classes. Currently I'm fine with "override".</div></div></blockquote><div><br></div><div>Java, Scala, use override in both contacts - no problems. </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 dir="auto"><br><blockquote type="cite"><div><div><div><div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> 3. Allow protocols to directly specify an implementation as well as via an extension, also see point 1 and note dynamic dispatch.</span></font></div></div></div></div></div></blockquote><div><br></div><div>I like the separation between "required signatures" and default implementations. The protocol body shouldn't be cluttered with implementations. Extensions also group default implementations for different type constraints.</div></div></blockquote><div><br></div><div>Not taking that away. However it is quite a lot of boiler plate for a small class and as acknowledged by Chris Lattner already on the things to do list. </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 dir="auto"><br><blockquote type="cite"><div><div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> 4. Allow via the default keyword protocols to define properties (including stored), initialisers, and functions that are part of the default implementation of the protocol but not the protocol itself.</span></font></div></div></div></blockquote><div><br></div><div>I'm skeptical about stored properties in protocols (multiple inheritance => diamond problem).</div></div></blockquote><div><br></div><div>No stored property in the protocol, just getter and setters. The actual stored property is only in the struct. </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 dir="auto"><div><br></div><div>A "default" keyword would definitely help to distinguish between <span style="background-color:rgba(255,255,255,0)">properties/methods with </span>default implementations and the ones without them.</div></div></blockquote><div><br></div><div>Yes default is necessary to distinguish the two uses. </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 dir="auto"><br><blockquote type="cite"><div><div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> 5. In the case of a default stored property the </span></font></div></div></div></blockquote><div><br></div><div>... ? :)</div></div></blockquote><div><br></div><div>Oops. Meant to say: <span style="background-color:rgba(255,255,255,0)">5. In the case of a default stored property the protocol has the appropriate calculated property, nothing is added to the extension, and the struct has the actual stored property.</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 dir="auto"><br><blockquote type="cite"><div><div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> 6. Allow the protocol name to be used to call the initialiser and in such cases use the default implementation.</span></font></div></div><br></div></blockquote><div><br></div><div><div><span style="background-color:rgba(255,255,255,0)">What will happen if not all requirements are fulfilled by default implementations? Also consider multiple inheritance.</span></div></div><div>Should there be an "init" which takes the remaining properties?</div></div></blockquote><div> </div><div>A. If the default implementation does not fulfil all the requirements then it is an error, just like a struct has to fulfil all the requirements.</div><div><br></div><div>B. It only has multiple inheritance of protocols, like Swift already has. The default is a struct, therefore both final and can only inherit from protocols.</div><div><br></div><div>C. You need to write default inits as necessary to make a valid protocol. For example if you have a private stored property then it won't be in the protocol but in the struct and all the inits will need to ensure it is initialised, just like normal.</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 dir="auto"><div><br></div><div>This reminds me of the "memberwise init" proposal...</div></div></blockquote><div><br></div><div>Not sure I follow your thinking on this. </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 dir="auto"><div><br></div><div><br></div><div>Best regards</div><span class=""><font color="#888888"><div>- Maximilian</div><br><blockquote type="cite"><div><br>-- <br> -- Howard.<br><br>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></font></span></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"> -- Howard.<br></div>
</div></div>