<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:16 PM, Chris Lattner &lt;<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</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="">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 class="">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 class=""><br class=""></div><div class="">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></div></blockquote><br class=""></div><div>To elaborate on this point, Swift does not include keywords to be able to spell the default for lots of things. &nbsp;If we did, we would have to have things like “nonfinal”, “strong”, etc. &nbsp;Adding these would not make the language better.</div><div><br class=""></div><div>As I pointed out on the enum discussion upthread, the interesting thing is to add a *clang* attribute for nonexhaustive, which I thought already exists, but I don’t see in the clang language extensions documentation at&nbsp;<a href="https://clang.llvm.org/docs/LanguageExtensions.html" class="">https://clang.llvm.org/docs/LanguageExtensions.html</a></div><div><br class=""></div><div>-Chris</div><div>&nbsp;</div><br class=""></body></html>