<div dir="ltr"><div><br></div><div class="gmail_extra"><div class="gmail_quote">2017-01-20 16:11 GMT+09:00 Slava Pestov <span dir="ltr">&lt;<a href="mailto:spestov@apple.com" target="_blank">spestov@apple.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Is your proposal to ban calls to such mutating methods on a type that is known to be a reference type at compile time altogether? This will create an inconsistency between code that operates on concrete types and code that operates on generic parameters (in the latter case the compiler of course has no way to statically guarantee that the value is not a reference type).</div><div> <br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>The last time this quirk came up in internal discussions, the thought some of us had was that it might be worthwhile to prohibit classes from conforming to protocols with mutating requirements altogether. If you think about it, this makes some amount of sense — it seems like it would be quite hard to write code that can operate on both mutable values and mutable references generically, since the latter do not have value semantics:</div><div><br></div><div>var x = y</div><div>x.mutatingProtocolRequirement(<wbr>)</div><div>// did y change too?</div><div><br></div><div>However the discussion sort of fizzled out.</div><div><br></div><div>Perhaps we can resurrect it as a proposal, but the bar is pretty high for removing features at this point, since there’s no actual type soundness issue, just possible confusion.</div><span class="gmail-"><div><br></div></span></div></blockquote><div><br></div><div>Well, I&#39;m not proposing anything for now.</div><div>I&#39;m totally OK to leave it as is if the community think so.</div><div>If so, I just want to confirm that the language feature truly support this.</div><div>At least, I don&#39;t want to propose something that breaks source compatibility.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><span class="gmail-"><div><blockquote type="cite"><div><div dir="ltr"><div><div class="gmail-m_1961095865702167157m_2220125713830145999m_-5113574630879694870gmail_msg"><div class="gmail-m_1961095865702167157m_2220125713830145999m_-5113574630879694870gmail_msg"><h3 style="box-sizing:border-box;margin-top:24px;margin-bottom:16px;font-size:1.25em;line-height:1.25;color:rgb(51,51,51);font-family:-apple-system,blinkmacsystemfont,&quot;segoe ui&quot;,helvetica,arial,sans-serif,&quot;apple color emoji&quot;,&quot;segoe ui emoji&quot;,&quot;segoe ui symbol&quot;" class="gmail-m_1961095865702167157m_2220125713830145999m_-5113574630879694870gmail_msg">Default implementation for initializers</h3><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,blinkmacsystemfont,&quot;segoe ui&quot;,helvetica,arial,sans-serif,&quot;apple color emoji&quot;,&quot;segoe ui emoji&quot;,&quot;segoe ui symbol&quot;;font-size:16px" class="gmail-m_1961095865702167157m_2220125713830145999m_-5113574630879694870gmail_msg">Similar to methods, initializers also have this issue:</p></div></div></div></div></div></blockquote></div></span>In the specific case of initializers, my opinion here is the opposite in fact — I think assigning to ‘self’ should be permitted in all convenience initializers, even initializers defined directly classes, without the protocol extension trick. Also, we should lower this more efficiently than we do today, without creating a self ‘carcass’ that is allocated and immediately freed, to be replaced by the ‘real’ self.<div><br></div></div></blockquote><div><br></div><div>I totally agree. And I think that is the least impact way on the language specification.</div><div><br></div></div></div></div>