<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 <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</a>> 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 <<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>> 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”. 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. 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. 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. It should be the default. Swift doesn’t have keywords to redundantly specify the default unless there is a specific reason to be able to do that. </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. If we did, we would have to have things like “nonfinal”, “strong”, etc. 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 <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> </div><br class=""></body></html>