[swift-evolution] Enums and Source Compatibility

[Jordan Rose]

> On Aug 10, 2017, at 09:15, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On 10.08.2017 18:22, Adrian Zubarev via swift-evolution wrote:
>> I think this design does not avoid you writing something like `private enum Foo { default ... }`, which is redudant as Jordan already pointed out in his previous post, nor does it have a consistent way of declaration:
> 
> Why compiler can't require 'open' enums to be public only? So, you can write but this will not compile. No?
> 
>> enum Foo {
>>   case abc
>>   case def
>>   default
>> }
>> enum Foo {
>>   case abc
>>   default
>>   case def
>> }
>> enum Foo {
>>   default
>>   case abc
>>   case def
>> }
>> ----
> 
> Why compiler can't require 'default' be declared only after last 'case' ?
> 
>> On the other hand I'd be very much in favor of the design David has pitched, which makes `public` as a soft default for public API's and adds a stronger constraints with an extra keyword OR a different access modifier. In case of an access modifier it would be really interesting if someone knows other use cases where we could reuse `closed` for similar purposes.
>> Long story short:
>> - public is the soft default and all uses of an enum from module A in module B would require `default` in swithch statements
>> - closed is the stronger implied `public` which makes the enum finite and does not require `default` if you switch on all cases
> 
> Can't agree. Default-like 'public' for class also allows compiler to make its optimizations as it is known that there can't be a subclass of published class.
> 
> 'public' for enum will in inverse block optimizations, as there is no guarantee that enum will be the same and will not change in future.

Without commenting on the rest of this at the moment, this is incorrect. A 'public' class may have subclasses in the same module (public or non-public), and a 'public' class in a binary framework is also permitted to become 'open' in the future.

Jordan


> 
> IMO the developer of external API should explicitly mark public enum as 'closed' or as 'open', to be concrete if changes in enum should/will lead to new major version of framework(so can't be changed in current version) or most likely this enum will be extended in next minor update and then "it might suddenly grow a new case containing a struct with 5000 Strings in it"(Jordan Rose)