> On Feb 11, 2017, at 2:41 PM, Karl Wagner via swift-evolution 
> <swift-evolution@swift.org> wrote:

> For example, the compiler squashes the layout of an enum in to the smallest 
> type which can represent all of its cases - so if you only have 2 cases, your 
> enum will be an Int1 (possibly stored in a way which overlaps the payload, if 
> there are spare bits to do so).

This is still the case with resilient enums. The current implementation of 
resilient value types does not change the memory layout of those types. Rather, 
it makes clients access the values indirectly, using a value witness table 
instead of making assumptions about the size, etc.

> 
> If we introduce some kind of forwards-compatible enum, it should explicitly 
> be something different (like an “open” enum). It’s the nichest of 
> niche-cases, would change the layout and prohibit optimisations, and make 
> those objects more difficult to reason about.

Perhaps, but note that resilience does *not* prohibit layout optimizations — 
instead, it means that clients use an indirect access pattern where knowledge 
of the layout is encapsulated in the library.

Slava

> 
>> 
>>>  
>>>> 3. In Swift 5, upgrade the warning to an error for non-exhaustiveness if a 
>>>> switch statement over a public enum doesn't have a `default` statement. 
>>>> Now, new syntax to extend an `open enum` can be introduced and the 
>>>> compiler can treat closed and public enums differently.
>>> 
>>> If the community and core team support this strategy I will also.  It seems 
>>> reasonable and speeds up the transition by using the point release.  That's 
>>> a great idea!
>>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to