<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=""><blockquote type="cite" class="">On Aug 24, 2016, at 3:39 AM, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></blockquote><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><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="">To take your example of walk(). Perhaps we have a protocol ‘Walkable’ which refers to any data structure where the nodes can be walked using the ‘walk()’ function. It is easy to imagine two different protocols A & B which specialize on this in different ways (say LinearWalkable & RandomWalkable), and both add some methods/properties and use those to provide efficient default implementations. At some point, you may run into a data structure which could easily be walked in both ways.</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="">As things are right now, you couldn’t inherit from both protocols. While you could add new ‘linearWalk()’ & ‘randomWalk()’ to the protocols respectively (cluttering their interface), there is still the issue of what to do when 'walk()’ is called. You can’t rename walk() in the originating protocols because it comes from their common ancestor. Much better to force one (or both) of the methods to be renamed on the conforming data structure. That keeps the interfaces of the protocols clean and makes the options available on the data structure clearer (e.g. ‘walk()’ & ‘randomWalk()’ )</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="">What I have had to do in the current version is inherit from the original protocol and then copy and paste the default implementations from the specialized versions. Now my code has been duplicated and is harder to maintain. We can do better.</div></div></blockquote></div><br class=""><div class="">I had a very similar situation, in fact. I solved it like this (using your protocol names for the purpose of making it easily contrastable):</div><div class=""><br class=""></div><div class="">protocol Walkable {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func walk()</div><div class="">}</div><div class=""><br class=""></div><div class="">protocol LinearWalkable: Walkable {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func linearWalk()<span class="Apple-tab-span" style="white-space:pre"> </span></div><div class="">}</div><div class=""><br class=""></div><div class="">extension LinearWalkable {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func linearWalk { … }</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func walk() { self.linearWalk() }</div><div class="">}</div><div class=""><br class=""></div><div class="">protocol RandomWalkable {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func randomWalk()</div><div class="">}</div><div class=""><br class=""></div><div class="">extension RandomWalkable {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func randomWalk() { … }</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func walk() { self.randomWalk() }</div><div class="">}</div><div class=""><br class=""></div><div class="">struct S: LinearWalkable, RandomWalkable {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func walk() { self.linearWalk() }</div><div class="">}</div><div class=""><br class=""></div><div class="">Thus a type that implements one or the other of the protocols gets walk() automatically doing the right thing, and a type that implements both has to explicitly choose. This way at least avoids the duplication of code; however, it is quite ugly to have to systematically duplicate essentially every method in the protocols (and there turned out to be quite a few of these).</div><div class=""><br class=""></div><div class="">Charles</div><div class=""><br class=""></div></body></html>