<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 Oct 3, 2017, at 10:11 PM, Slava Pestov &lt;<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="Singleton" style="word-wrap: break-word; -webkit-nbsp-mode: space;"><div class=""><blockquote type="cite" class="" 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-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space;"><div class="">However I’m still waiting for Dave or Jordan to chime in with the original justification for the ‘always emit into client’ behavior. IIRC there was a resilience-related argument too, but I don’t remember what it is now.</div></div></div></blockquote><br class=""></div><div class="">The only argument I can imagine is the “If it gets inlined, you’re guaranteed to get the version of the symbol you build against”. &nbsp;The concern is that some instances are inlined and some are not, and if the inline and out of line versions diverge then you can have exciting problems.</div><div class=""><br class=""></div><div class="">My view on that is that you’ve already lost if you’d done this. &nbsp;If you mark a declaration as fragile (allowing it to be inlined) you’ve specifically guaranteed that you’re not going to be changing the observable semantics of the function. &nbsp;Introducing new performance optimizations is fine of course.</div></div></div></blockquote><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></div><div class="">I understand your reasoning here, but note that in Jordan’s proposal, he’s adding two new keywords, exhaustive and nonexhaustive. If exhaustive becomes @fragile, does nonexhaustive still make sense?</div></div></div></blockquote><br class=""></div><div>Independently of how exhaustive is spelled, nonexhaustive doesn’t make sense to me. &nbsp;It should be the default. &nbsp;Swift doesn’t have keywords to redundantly specify the default unless there is a specific reason to be able to do that. &nbsp;</div><div><br class=""></div><div>The example often cited is “nonmutating”, but it isn’t there to cover the default: it is specifically required because setters default to mutating so it must exist to be change that default.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div></body></html>