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


swift-evolution mailing list

Reply via email to