[swift-evolution] [Pitch] consistent public access modifiers

[Slava Pestov]

> On Feb 11, 2017, at 2:41 PM, Karl Wagner via swift-evolution <swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170212/69bbf932/attachment.html>