[swift-evolution] Enums and Source Compatibility

[Jordan Rose]

> On Sep 22, 2017, at 08:20, Karl Wagner <razielim at gmail.com> wrote:
> 
> 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.

As I've mentioned before, unifying all these things is not a good idea because they affect clients in different ways. That is, clients need to know about some of these and not others, and library authors probably shouldn't be considering them all to be equivalent.

- Exhaustivity, of course, affects diagnostics around 'switch' statements.

- 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.

- The unformalized function attribute currently spelled '@_inlinable' ought to be in the same bucket as '@_fixedLayout', but in practice I'm not sure we'll be able to make everything 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.

- 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'.

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.


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.)

Jordan


* 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170928/97ff8292/attachment.html>