<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 11, 2015, at 11:43 AM, Gwendal Roué &lt;<a href="mailto:gwendal.roue@gmail.com" class="">gwendal.roue@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 11 déc. 2015 à 20:34, Slava Pestov via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; a écrit :</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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="">For this reason I’m in favor of going in the opposite direction, and prohibiting classes from conforming to protocols with mutating requirements.</div></div></blockquote><br class=""></div><div class="">This would go too far.</div><div class=""><br class=""></div><div class="">It’s common to write a protocol with mutating methods just because the protocol designer expects that some adopting structs may want to mutate in their implementation. And in this case the goal of the protocol designer is certainly not to limit the protocol adoption to structs.</div><div class=""><br class=""></div><div class="">Here is an example:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>protocol DatabaseFetchable {</div><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>&nbsp; mutating func awakeFromFetch()</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>}</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>extension DatabaseFetchable {</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>&nbsp; func fetch() -&gt; Self {</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>&nbsp; &nbsp; var value = /* details omitted */</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>&nbsp; &nbsp; value.awakeFromFetch()</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>&nbsp; &nbsp; return value</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>&nbsp;&nbsp;}</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>}</div><div class=""><br class=""></div><div class="">The protocol does not care at all if awakeFromFetch mutates or not. But the protocol designer does: if the awakeFromFetch method were not declared mutating, many structs could simply not adopt it.</div><div class=""><br class=""></div><div class="">Gwendal Roué</div><div class=""><br class=""></div></div></div></blockquote></div><br class=""><div class="">I guess the question is, does it even make sense to write a protocol that can be adopted by both a struct and a class, if the protocol has mutating members?</div><div class=""><br class=""></div><div class="">Slava</div></body></html>