[swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

[Slava Pestov]

> On Dec 22, 2017, at 9:55 AM, Chris Lattner <clattner at nondot.org> wrote:

> When and if we add private cases to enums, we’ll need to be able to associate an availability range with an “exhaustive” marker.  When/if that happens, then yes, we should do so through @available(exhaustive: iOS41, *).    The @exhaustive attribute will become sugar for “born exhaustive”, because in the absence of private cases the availability range doesn’t matter (AFAIK).

It still matters if the enum was not “born exhaustive”. Recall that non-exhaustive enums and non-fixed contents structs are address-only types, because we don’t know their size at compile time and so they must be passed indirectly. So if your framework defines a non-exhaustive enum and a function taking or returning this enum, the calling convention will change if the enum becomes exhaustive (unless one of its cases is address-only for some other reason). So we will need to use availability ranges to declare that an enum became exhaustive after the fact. Such an enum will still be treated as non-exhaustive in the calling convention, but can otherwise be manipulated directly (as long as your deployment target is more recent than when it became exhaustive).

Slava