> On Aug 10, 2017, at 09:15, Vladimir.S via swift-evolution
> <swift-evolution@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)
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
