> On Aug 10, 2017, at 3:52 PM, David Hart via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
> 
> On 10 Aug 2017, at 22:36, Adrian Zubarev <adrian.zuba...@devandartist.com 
> <mailto:adrian.zuba...@devandartist.com>> wrote:
> 
>> Okay I came to the conclusion that this won’t work that easily. Here is my 
>> reasoning why I think that way. If one assume for a second that one day we 
>> might have value sub typing - yes not now and not in the next Swift version, 
>> but hear me out please - we will come back and discuss the alignment of 
>> `open/public` for value types (including enums of course)
> 
> Does value sub-typing really imply overriding? Because if that’s not the 
> case, we won’t need the open keyword to limit overriding.

It definitely does not in my opinion.  Value sub typing is effectively a form 
of implicit conversion that is guaranteed to succeed in producing a value of a 
different type (typically with a large set of inhabitants) that is logically 
equivalent.

> 
>> which would allow us to create sub/super Types of an enum from module A in 
>> module B with `open` modifier, where on the other hand `public` would 
>> restrict sub/supertyping to the module where the enum is defined, very 
>> similar to classes. Here is the tricky part now. If we’d add a `closed` 
>> modifier which implies `public` then we end up with a hole that cannot be 
>> filled at that point of time, because we would only be able to declare a 
>> public-but-open and a public-but-closed enum. However we still would need be 
>> able to create an open-but-open enum (lhs open is the constraints for sub 
>> typing, rhs open is the constraint that we talk about in this thread). 
>> Therefore to support open-but-open version we would require a special 
>> keyword.
>> 
>> I want to modify your main idea into:
>> 
>> (Potentially possible in the future)
>> - open-but-finite enum - or simply: open finite enum
>> - open-but-infinite enum - or simply: open enum
>> 
>> (Version that we could make possible in Swift 5)
>> - public-but-finite enum - or simply: public finite enum
>> - public-but-infinite enum - or simply: public enum
>> 
>> 
>> Am 10. August 2017 um 22:00:40, David Hart (da...@hartbit.com 
>> <mailto:da...@hartbit.com>) schrieb:
>> 
>>> 
>>> 
>>> On 10 Aug 2017, at 19:19, Jordan Rose <jordan_r...@apple.com 
>>> <mailto:jordan_r...@apple.com>> wrote:
>>> 
>>>> 
>>>> 
>>>>> On Aug 9, 2017, at 22:46, David Hart <da...@hartbit.com 
>>>>> <mailto:da...@hartbit.com>> wrote:
>>>>> 
>>>>> 
>>>>>> On 10 Aug 2017, at 02:42, Jordan Rose <jordan_r...@apple.com 
>>>>>> <mailto:jordan_r...@apple.com>> wrote:
>>>>>> 
>>>>>> :-) As you've all noted, there are some conflicting concerns for the 
>>>>>> default:
>>>>>> 
>>>>>> - Source compatibility: the existing behavior for an unannotated enum is 
>>>>>> "closed".
>>>>>> - Intuition: if you show someone an enum without an explicit annotation, 
>>>>>> they'll probably expect they can switch over it. (I'm going to say this 
>>>>>> is why Zach calls it a "sensible default".)
>>>>>> - Consistency: switches on an enum in the same module can always be 
>>>>>> exhaustive, so having it be different across modules is a bit annoying. 
>>>>>> (But 'public' already acts like this.)
>>>>>> 
>>>>>> vs.
>>>>>> 
>>>>>> - Library evolution: the default should promise less, so that you have 
>>>>>> the opportunity to change it.
>>>>>> - Flexibility: you can emulate an exhaustive switch with a 
>>>>>> non-exhaustive switch using fatalError, but not the other way around.
>>>>>> 
>>>>>> All of this is why I suggested it be an explicit annotation in either 
>>>>>> direction, but Matthew brought up the "keyword soup" problem—if you have 
>>>>>> to write (say) "public finite enum" and "public infinite enum", but 
>>>>>> would never write "private finite enum" or "private infinite enum", 
>>>>>> something is redundant here. Still, I'm uncomfortable with the default 
>>>>>> case being the one that constrains library authors, so at least for 
>>>>>> binary frameworks (those compiled "with resilience") I would want that 
>>>>>> to be explicit. That brings us to one more concern: how different should 
>>>>>> binary frameworks be from source frameworks?
>>>>> 
>>>>> In terms of intuition and consistency, I think we should really try to 
>>>>> learn from the simplicity of public/open:
>>>>> 
>>>>> * When internal, classes are sub-classable by default for convenience, 
>>>>> but can be closed with the final keyword
>>>>> * When public, classes are closed to sub-classing for safety, but can be 
>>>>> opened up with the open keyword (which implies public).
>>>>> 
>>>>> If we try to mirror this behaviour (the keywords are just suggestions, 
>>>>> not important):
>>>>> 
>>>>> * When internal, enums are exhaustive by default for convenience, but can 
>>>>> be opened-up with the partial keyword
>>>>> * When public, enums are non-exhaustive by default for safety, but can be 
>>>>> made exhaustive with the exhaustive keyword (which implies public).
>>>> 
>>>> This is not a correct understanding of the internal/public distinction for 
>>>> classes, though. From inside a module, a public-but-not-open class is 
>>>> still subclassable, and similarly a public-but-not-"closed" enum will 
>>>> still be exhaustively switched. You don't have to worry about your own 
>>>> module changing out from under you.
>>> 
>>> Correct. Thanks for the clarification! But you still agree with the 
>>> argument, right? Convenience for same module enums (exhaustive by default), 
>>> safety for clients of the module (not-exhaustive when public from outside 
>>> the module), with the option to be explicit? And what do you think of the 
>>> idea of having the « exhaustiveness » modifier imply public, like open does?
>>> 
>>>> Jordan
>>>> 
> _______________________________________________
> 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