<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 22, 2017, at 08:20, Karl Wagner <<a href="mailto:razielim@gmail.com" class="">razielim@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div 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;" class="">So I’m in favour of the change, but absolutely not in favour of the keywords. We need to standardise a minimal set of keywords which broadly cover the things library authors need to care about (versioning, sub-typing, inlining, etc). How is “exhaustive” different from “final” or “@_versioned”? How do they interact? I think we could come up with a more coherent message.</div></div></blockquote><br class=""></div><div>As I've mentioned before, unifying all these things is not a good idea because they affect <i class="">clients</i> in different ways. That is, clients need to know about some of these and not others, and library authors probably <i class="">shouldn't</i> be considering them all to be equivalent.</div><div><br class=""></div><div>- Exhaustivity, of course, affects diagnostics around 'switch' statements.</div><div><br class=""></div><div>- The unformalized struct attribute currently spelled '@_fixedLayout' is an optimization hint that only matters for binary frameworks*; any struct in a library you build from source can have its layout guaranteed to clients.</div><div><br class=""></div><div>- The unformalized function attribute currently spelled '@_inlinable' <i class="">ought</i> to be in the same bucket as '@_fixedLayout', but in practice I'm not sure we'll be able to make <i class="">everything</i> inlinable and still support fast compilation (yes, yes, go ahead and laugh). This might remain a user-specified attribute for a while, in the same way that you have to manually decide to make certain operations into `static inline` functions in C-based languages.</div><div><br class=""></div><div>- The unformalized attribute currently spelled '@_versioned' is basically "public but hidden", in that it makes a declaration part of your ABI without making it part of your API. This is related to the other attributes, but I don't think it's the same thing. It's also mostly unrelated to what the Library Evolution document calls "versioning"; it's standing in for a proper availability annotation on a declaration that's 'internal' rather than 'public'.</div><div><br class=""></div><div>I could see the latter three being related, but I think there's a definite reason to keep exhaustivity separate. It's more similar to existing modifiers like 'open' than to ABI- and optimization-related annotations like '@_fixedLayout'; it's just too bad that 'open' has the reverse connotations from what we need.</div><div><br class=""></div><div><br class=""></div><div>That said, I'd actually be fine with `final`. Like exhaustivity, `final` allows clients outside the original library to do things they otherwise wouldn't be able to: add 'required' initializers. (It also has effects within the module, which exhaustivity doesn't, but that seems okay to me.)</div><div><br class=""></div><div>Jordan</div><br class=""><div class=""><br class=""></div><div class="">* I'm using "binary frameworks" to mean "libraries with binary compatibility requirements" again; a pre-built library that's embedded with an app doesn't run into these issues.</div></body></html>