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