[swift-evolution] [Proposal] Enum subsets

[T.J. Usiyan]

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.

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> 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> 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>
> 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> 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)
>>
>> ## 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
>> 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/37460a72/attachment.html>