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 < [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
