<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body 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">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><br><blockquote type="cite"><div><div><br></div><div>Which gets translated to:</div><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></div></blockquote><div><br></div><div>That should probably be a separate proposal to make the current one more incremental.</div><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><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><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><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><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><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><br></div><div>This reminds me of the "memberwise init" proposal...</div><div><br></div><div><br></div><div>Best regards</div><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">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>