> On Dec 22, 2017, at 9:08 PM, Slava Pestov <spes...@apple.com> wrote: > > > >> On Dec 22, 2017, at 9:55 AM, Chris Lattner <clatt...@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).
Ok, makes sense to me. This is even more reason to provide a framework that scales to these unusual cases. :-) -Chris _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
