[swift-evolution] [Proposal] Enum subsets

[Erica Sadun]

A few ideas:

* Mention the pull request about member sets?
* I'd try to give some more compelling use cases (Where a union type can be broadly applied across more specific uses, which then tend to narrow the applicable cases, and you want to limit (and compile check) those cases while inheriting behavior).
* Mention how enum specialization tends to limit possible cases, and consider how enum expansion/inheritance might be another direction for expanding existing enums (for example, when adding new phone models, but using an existing enum, with an extension), and how this might impact footprint in associated types.
* Discuss how behavior extensions on narrowed enums could be limited to the subset, so would be syntactically limited to the semantic subset as a motivation for why LCD colors might appropriately be used in a calibrate functions but the full color cases would not, etc.

-- E



> On Jun 3, 2016, at 3:35 PM, T.J. Usiyan via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Since this seems to have some interest, I've made a gist.
> 
> https://gist.github.com/griotspeak/963bc87a0c244c120264b11fb022d78c <https://gist.github.com/griotspeak/963bc87a0c244c120264b11fb022d78c>
> 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 <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/020025.html>
> Motivation
> 
> Consider a situation where we have an enum Color 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 .
> 
> enum Color {
>     case red, orange, yellow, green, blue, indigo, violet
>     …
> }
> 
> enum LCDColor {
>     case red, green, blue
> }
> The cases in LCDColor in our scenario do not require different behavior from their similarly named cases in Color. 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 LCDColor
> - Completely manually
> - Protocols with ‘minimal’ manual duplication
> 2. Avoid duplication by allowing conversion to Color. 
> 
> Neither of these solutions make the subset relationship between Color and LCDColor clear or strict.
> 
> Proposed solution
> 
> Add syntax to describe a restricted set of cases from an enum. 
> 
> typealias LCDColor = Color.(red|green|blue)
> LCDColor has all of the type and instance methods of Color.
> 
> Barring any technical reason, the ‘actual’ name of the type, in this example, is Color.(red|green|blue) This makes the relationship to Colorsyntactically clear. If a typealias is not desired, Color.(red|green|blue) should refer to the same type as LCDColor
> Switching over Color.(red|green|blue) should only need to be exhaustive for the three cases .red, .green, and .blue.
> Two initializers should be implicitly created
> Color to LCDColor?
> returns nil for all cases not in LCDColor
> LCDColor to Color
> Obvious and trivial implementation mapping cases from LCDColor to Color
> Casting should be allowed
> from superset to subset only using as? or as! syntax.
> from subset to superset using as
> Creating subsets of subsets is not allowed but reasonable conversions among subsets should be allowed if technically feasible such that:
> Given subsets of C A and B, where A is a superset of B, the casting relationship between A and B should be similar to that between C and either of the other two named subsets.
> 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.
> If a mangled name approach is taken, the ordering of cases should be sorted to ensure stability.
> 
> Alternatives considered
> 
> Do nothing. This feature is not strictly necessary but does allow for expressivity not currently available in the language.
> implicitly create properties which convert to superset type.
> Impact on existing code
> 
> This is an additive change which should have no breaking change to existing code.
> 
> 
> On Fri, Jun 3, 2016 at 4:57 PM, Austin Zheng <austinzheng at gmail.com <mailto:austinzheng at gmail.com>> wrote:
> I really like the idea behind this proposal.
> 
> Some questions:
> 
> - Would the enum 'slice' be a distinct type relative to the base enum?
> - On a related note, would shared cases between the sliced enum and the base enum be implicitly convertible?
> - If they aren't implicitly convertible between each other, would there be an affordance to perform conversions (e.g. a "parentEnumType" property and an "init?(parentEnumType:)" initializer)/
> - Would you be able to further slice a sliced enum? If so, would they share the same parent, or would the 'parent' of the sliced sliced enum be the sliced enum?
> - If the parent enum has members that switch on 'self', would those members be available to the child automatically?
> - What happens if you have two (or more) slices with disjoint members? (e.g. 'LCDColors' and 'TrafficLightColors') Would they be considered completely separate 'sub-types'?
> 
> Best,
> Austin
> 
> 
> 
> 
> On Fri, Jun 3, 2016 at 6: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/80897d17/attachment.html>