[swift-evolution] [Proposal] Enum subsets
Christopher Kornher
ckornher at me.com
Fri Jun 3 16:47:28 CDT 2016
The syntax I described here has a number of problems, among them being:
1) Creating a supersets in the way described breaks down badly when the declarations exist within multiple modules.
2) The empty enum declaration is currently illegal and probably should be
3) The superset declaration contains no clue as to what it really is.
4) Possibly the most commonly needed use case is not possible with this syntax: Extending enums defined in other modules
I believe that best solution is explicit ```subset:``` and ‘’’superset:``` relationships. They could be added to the language at the same time, or not, but it seems to make sense to consider the possibility of creating supersets along with creating subsets.
I will take more time to think this through before I reply again. It would be nice not to add a variation to ```:``` but that is the best syntax I could think of at the time.
> On Jun 3, 2016, at 2:18 PM, T.J. Usiyan via swift-evolution <swift-evolution at swift.org> wrote:
>
> My only hesitation with using `enum LCDColors : Colors` is that that syntax usually signals extending a type and I am not sure whether I am advocating for the ability to add something to `LCDColors` without adding it to `Colors`. I envisioned it as 'simply a subset of cases' but that is probably just limited vision on my part.
I agree.
>
> Using the subtype syntax works for the most part, so I could certainly live with it.
>
> On Fri, Jun 3, 2016 at 3:56 PM, Christopher Kornher <ckornher at me.com <mailto:ckornher at me.com>> wrote:
> Your original syntax makes LCDColors clearly a type. The typealias obscures the fact that a new type is being created. An alternative might be something like:
>
> ```
> enum LCDColors : Colors {
> case red, green, blue
> }
> ```
>
> or perhaps
>
> ```
> enum LCDColors subset: Colors {
> case red, green, blue
> }
> ```
>
> This would would be compatible with something that I have been hoping for, creating superset enums from multiple enums for things like errors:
>
> ```
> enum AppErrors {
> // Defined by its subsets
> }
>
> enum NetworkingErrors subset: AppErrors {
> case NWError1 = 1000, NWError2. NWError3
> }
>
>
> enum UserInputErrors subset: AppErrors {
> case UIError1 = 2000, UIError2. UIError3
> }
> ```
> The compiler would have to check for rawValue collisions.
>
> having the superset enum define values that could be used in children would allow:
>
> ```
> enum AppErrors {
> // Defined by its subsets
> case NetworkingErrorBase = 1000
> case UIErrorBase = 2000
> }
>
> enum NetworkingErrors subset: AppErrors {
> case NWError1 = NetworkingErrorBase, NWError2. NWError3
> }
>
> enum UserInputErrors subset: AppErrors {
> case UIError1 = UIErrorBase, UIError2. UIError3
> }
> ```
>
>> On Jun 3, 2016, at 10:39 AM, T.J. Usiyan via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>> I don't have a problem with something as explicit as that. I was mostly avoiding adding keywords with my proposed syntax. I have basically no tie to the proposed syntax.
>>
>> TJ
>>
>> On Fri, Jun 3, 2016 at 12:32 PM, Christopher Kornher <ckornher at me.com <mailto:ckornher at me.com>> wrote:
>> This could be useful in categorizing and grouping within large enums ErrorType enums come to mind. Would there be any problem with making the subset more explicit? e.g.
>>
>>
>>
>> ``` swift
>> enum Colors {
>> case red, orange, yellow, green, blue, indigo, violet
>> …
>> }
>>
>> extension Colors {
>> subset LCDColors red, green, blue
>> }
>> ```
>>
>>> On Jun 3, 2016, at 7:22 AM, T.J. Usiyan via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>
>>> This is loosely related to but not meant to 'compete' with the ad hoc enum proposal.
>>>
>>> ## Introduction
>>>
>>> This proposal adds/creates syntax to allow ad hoc creation of enums whose members are strict subsets of explicitly defined enums.
>>>
>>> Swift-evolution thread: [Discussion thread topic for that proposal](http://news.gmane.org/gmane.comp.lang.swift.evolution <http://news.gmane.org/gmane.comp.lang.swift.evolution>)
>>>
>>> ## Motivation
>>> Consider a situation where we have an enum `Colors` which represents the entire set of colors relevant to your application with many salient methods and operations. We have also declared an enum `LCDColorModel` with only three colors, `red, blue, green` .
>>>
>>> ``` swift
>>> enum Colors {
>>> case red, orange, yellow, green, blue, indigo, violet
>>> …
>>> }
>>>
>>> enum LCDColors {
>>> case red, green, blue
>>> }
>>> ```
>>>
>>> The cases in `LCDColors` in our scenario do not require different behavior from their similarly named cases in `Colors`. We would like, simply stated, to explicitly restrict the cases allowed within a specific portion of our software. There are, currently, a few approaches
>>> 1. Duplicate functionality in `LCDColors`
>>> - Completely manually
>>> - Protocols with 'minimal' manual duplication
>>> 2. Avoid duplication by allowing conversion to `Colors`.
>>>
>>> Neither of these solutions make the subset relationship between `Colors` and `LCDColors` clear or strict.
>>
>>> ## Proposed solution
>>>
>>> Add syntax to describe a restricted set of cases from an enum.
>>>
>>> ```swift
>>> typealias LCDColors = Colors.(red|green|blue)
>>> ```
>>>
>>> `LCDColors ` has all of the type and instance methods of `Colors`. Cases must appear in the same order as their original declaration.
>>>
>>>
>>> ## Detailed design
>>>
>>> While I am unsure of the entirety of the design, I propose that name mangling be used which, along with the declaration order restriction should mean that all possible subsets have a stable and predictable name which contains all of the information necessary to infer cases.
>>>
>>> ## Impact on existing code
>>>
>>> This is an additive change which should have no breaking change to existing code.
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160603/3b30387e/attachment.html>
More information about the swift-evolution
mailing list