“… what you're describing isn't really an enum"
I’ve gotten this explanation before in reference to errors. I am confused as to
what constitutes an enum and what doesn’t.
-Kenny
> On Sep 18, 2017, at 10:31 AM, Jordan Rose <jordan_r...@apple.com> wrote:
>
> As mentioned, the right way to do this is with a struct:
>
> public struct ConnectionDictionaryKey: RawRepresentable, Hashable {
> public var rawValue: String
> public init(rawValue: String) { … }
> public init(_ rawValue: String) { … }
> }
> extension ConnectionDictionaryKey {
> static let hostName = ConnectionDictionaryKey("hostname")
> static let databaseName = ConnectionDictionaryKey("database")
> // …
> }
>
> It is definitely more verbose than an enum, and it may be worth a separate
> proposal to deal with that! But it is not part of this proposal, and what
> you're describing isn't really an enum.
>
> Jordan
>
>
>> On Sep 16, 2017, at 15:51, Kenny Leung via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> Oops, forgot something:
>>
>> "Can there be a kind of open enum where you can add new cases in extensions?”
>>
>> I have a use case for this. I’m trying to write a database ORM with abstract
>> API and concrete instances for different database. So I have defined:
>>
>> open class Database {
>> init(connectionDictionary: [ConnectionDictionaryKey:String]) {
>> self.connectionDictionary = connectionDictionary;
>> }
>> }
>>
>> Where I have ConnectionDictionaryKey defined as an enum, with values like
>> .hostName, .databaseName, .userName, .password, .databaseName, etc…
>>
>> But concrete databases may have other options that need to be added to the
>> connection dictionary. It would be nice if they could just extend
>> ConnectionDictionaryKey with new cases.
>>
>> -Kenny
>>
>>
>>> On Sep 16, 2017, at 3:35 PM, Kenny Leung via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>> In general, I agree with everything in the proposal.
>>>
>>> I’d like to propose these alternative extensions for clients:
>>>
>>> 1) As a client of an enum, I’d like to know in the future when a new value
>>> has been added to an enum, since I may have to do something about it. How
>>> about adding the “exhaustive” keyword to be used in the switch statement?
>>> Like
>>>
>>> exhaustive switch excuse {
>>> case eatenByPet:
>>> // …
>>> case thoughtItWasDueNextWeek:
>>> // …
>>> default:
>>> // …
>>> }
>>>
>>> If exhaustive is used, there would be a warning if all cases aren’t covered
>>> *even though default exists*. This means that I as the client thought I had
>>> everything covered when I wrote this code.
>>>
>>> As already mentioned, this makes the default case un-testable, which brings
>>> me to
>>>
>>> 2) All non-exhaustive enums should have the pseudo value “default” that can
>>> be used just like a regular value. This would allow you to write code like:
>>>
>>> teacher.failedToHandInHomework(excuse: .default)
>>>
>>> which would allow you to trip the default case in any code you may write.
>>>
>>> -Kenny
>>>
>>>
>>>> On Sep 13, 2017, at 12:17 PM, Jordan Rose via swift-evolution
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>
>>>> Proposal updated, same URL:
>>>> https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/nnnn-non-exhaustive-enums.md
>>>>
>>>> <https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/nnnn-non-exhaustive-enums.md>.
>>>>
>>>> Thanks again for all the feedback so far, everyone!
>>>> Jordan
>>>>
>>>>
>>>>> On Sep 12, 2017, at 17:55, Jordan Rose via swift-evolution
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>
>>>>> Sorry, I got distracted by other tasks! Both the discussion here and
>>>>> within Apple has moved towards making "non-exhaustive" the default,
>>>>> which, to be honest, I too think is the best design. I'll update the
>>>>> proposal today to reflect that, though I still want to keep both the
>>>>> "nonexhaustive" and "exhaustive" keywords for Swift 4 compatibility for
>>>>> now (or whatever we end up naming them). The compatibility design is a
>>>>> little less ambitious than Brent's; as currently proposed, Swift 4 mode
>>>>> continues to default to 'exhaustive' all the time, even in the actual
>>>>> Swift 5 release.
>>>>>
>>>>> I still want to respond to Brent's points directly, but I think you and
>>>>> Vladimir have done a good job discussing them already. I'll send out the
>>>>> updated proposal tomorrow, after I have a little more time to think about
>>>>> #invalid.
>>>>>
>>>>> Thanks for putting time into this!
>>>>> Jordan
>>>>>
>>>>>
>>>>>> On Sep 9, 2017, at 17:34, Rod Brown <rodney.bro...@icloud.com
>>>>>> <mailto:rodney.bro...@icloud.com>> wrote:
>>>>>>
>>>>>> Jordan,
>>>>>>
>>>>>> Do you have any other thoughts about the ongoing discussion here,
>>>>>> especially regarding Chris’ comments? As you’re the one pushing this
>>>>>> forward, I’d really like to know what your thoughts are regarding this?
>>>>>>
>>>>>> - Rod
>>>>>
>>>>> _______________________________________________
>>>>> 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 <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
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
