> On Sep 22, 2017, at 08:20, Karl Wagner <razie...@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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
