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
> <[email protected]> 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
>> <[email protected] <mailto:[email protected]>> 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
>>> <[email protected] <mailto:[email protected]>> 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
>>>> <[email protected] <mailto:[email protected]>> 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 <[email protected]
>>>>> <mailto:[email protected]>> 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
>>>> [email protected] <mailto:[email protected]>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
