[swift-evolution] [Proposal] Enum subsets

[Haravikk]

I really like this idea, a few comments I have:
Would this subset be exhaustive within only the subset you’ve restricted it to? I’m hoping so! i.e- if I do a switch on LCDColors I assume I only have to provide three cases, but this doesn’t appear to be expressly mentioned.
Do you envision this being usable in function signatures without declaring a type alias first? I can see cases where it may be convenient to do so, but some of the concerns with ad-hoc enums has been over there being no formal declaration of the type.
Lastly, is the ordering of the labels really important? Can’t the compiler just reorder them behind the scenes if necessary? I don’t think there should be any problem with the compiler detecting that Colors.(violet|orange|green) is the same as Colors.(orange|green|violet). I mean it’d be good practice to maintain the same order of course, but I think it’s better to allow any order, as the parent type’s ordering may change and break stuff; I’m not sure if relying on the parent’s ordering is really wise anyway, if you need it for some purpose then it should be defined in a method.
You need to cover conversion between the two types. I assume that if I have an LCDColors case it will work anywhere that takes a case from Colors, but how does the reverse work? Can I assign an instance of Colors to LCDColors via casting for example (with a failure if it’s not one of the specified cases)?
But yeah, I like this idea, it’s kind of like an enum “slice”, and while it’s not strictly the same as ad-hoc enums it could solve many of their use-cases in a safer way.

> On 3 Jun 2016, at 14:22, 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 <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160603/5844fa5f/attachment.html>