[swift-evolution] [Proposal] Enum subsets

[Christopher Kornher]

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 <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
> 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/e56ba7cb/attachment.html>