<div dir="ltr">My only hesitation with using `<span style="font-size:13px">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.</span><div><span style="font-size:13px"><br></span></div><div>Using the subtype syntax works for the most part, so I could certainly live with it. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 3, 2016 at 3:56 PM, Christopher Kornher <span dir="ltr"><<a href="mailto:ckornher@me.com" target="_blank">ckornher@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>```</div><div>enum LCDColors : Colors {</div></div><div><div><span style="white-space:pre-wrap"> </span>case red, green, blue</div></div><div><div>}</div></div><div><div>```</div></div></blockquote><div><br></div><div>or perhaps</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>```</div><div>enum LCDColors subset: Colors {</div></div><div><div><span style="white-space:pre-wrap"> </span>case red, green, blue</div></div><div><div>}</div></div><div><div>```</div></div></blockquote><div><br></div><div>This would would be compatible with something that I have been hoping for, creating superset enums from multiple enums for things like errors:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>```</div><div>enum AppErrors {</div></div><div><div><span style="white-space:pre-wrap"> </span>// Defined by its subsets</div></div><div><div>}</div></div><div><div><br></div></div><div><div>enum NetworkingErrors subset: AppErrors {</div></div><div><div><div><span style="white-space:pre-wrap"> </span>case NWError1 = 1000, NWError2. NWError3</div></div></div><div><div><div>}</div></div></div><div><div><br></div></div><div><div> </div></div><div><div>enum UserInputErrors subset: AppErrors {</div></div><div><div><div><span style="white-space:pre-wrap"> </span>case UIError1 = 2000, UIError2. UIError3</div></div></div><div><div><div>}</div></div></div><div><div> ```</div></div></blockquote><div>The compiler would have to check for rawValue collisions.</div><div><br></div><div>having the superset enum define values that could be used in children would allow:</div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><br></div><div> ```</div><div>enum AppErrors {</div><div><div><span style="white-space:pre-wrap"> </span>// Defined by its subsets</div></div><div><div><span style="white-space:pre-wrap"> </span>case NetworkingErrorBase = 1000</div></div><div><div><span style="white-space:pre-wrap"> </span>case UIErrorBase = 2000</div></div><div><div>}</div></div><div><div><br></div></div><div><div>enum NetworkingErrors subset: AppErrors {</div></div><div><div><div><span style="white-space:pre-wrap"> </span>case NWError1 = NetworkingErrorBase, NWError2. NWError3</div></div></div><div><div><div>}</div></div></div><div><div><br></div></div><div><div>enum UserInputErrors subset: AppErrors {</div></div><div><div><div><span style="white-space:pre-wrap"> </span>case UIError1 = UIErrorBase, UIError2. UIError3</div></div></div><div><div><div>}</div></div></div><div><div> ```</div></div></blockquote><div><div class="h5"><br><div><blockquote type="cite"><div>On Jun 3, 2016, at 10:39 AM, T.J. Usiyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr">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.<div><br><div>TJ</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 3, 2016 at 12:32 PM, Christopher Kornher <span dir="ltr"><<a href="mailto:ckornher@me.com" target="_blank">ckornher@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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.</div><div><br></div><div><br></div><div><br></div><div><span>``` swift<br>enum Colors {<br><span style="white-space:pre-wrap"> </span>case red, orange, yellow, green, blue, indigo, violet<br><span style="white-space:pre-wrap"> </span>…<br>}<br><font color="#5856d6"><br></font></span>extension Colors {<br><span style="white-space:pre-wrap"> </span>subset LCDColors red, green, blue</div><div>}<br><div dir="ltr"><div>```</div></div></div><div><div dir="ltr"><div><br></div></div></div><div><div><div><blockquote type="cite"><div>On Jun 3, 2016, at 7:22 AM, T.J. Usiyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr"><div>This is loosely related to but not meant to 'compete' with the ad hoc enum proposal.</div><div><br></div><div>## Introduction</div><div><br></div><div>This proposal adds/creates syntax to allow ad hoc creation of enums whose members are strict subsets of explicitly defined enums.</div><div><br></div><div>Swift-evolution thread: [Discussion thread topic for that proposal](<a href="http://news.gmane.org/gmane.comp.lang.swift.evolution" target="_blank">http://news.gmane.org/gmane.comp.lang.swift.evolution</a>)</div><div><br></div><div>## Motivation</div><div>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` .</div><div><br></div><div>``` swift</div><div>enum Colors {</div><div><span style="white-space:pre-wrap"> </span>case red, orange, yellow, green, blue, indigo, violet</div><div><span style="white-space:pre-wrap"> </span>…</div><div>}</div><div><br></div><div>enum LCDColors {</div><div><span style="white-space:pre-wrap"> </span>case red, green, blue</div><div>}</div><div>```</div><div><br></div><div>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 </div><div><span style="white-space:pre-wrap"> </span>1. Duplicate functionality in `LCDColors` </div><div><span style="white-space:pre-wrap"> </span>- Completely manually</div><div><span style="white-space:pre-wrap"> </span>- Protocols with 'minimal' manual duplication</div><div><span style="white-space:pre-wrap"> </span>2. Avoid duplication by allowing conversion to `Colors`. </div><div><br></div><div>Neither of these solutions make the subset relationship between `Colors` and `LCDColors` clear or strict.</div></div></div></blockquote><div><br></div></div></div><blockquote type="cite"><div><div><div><div dir="ltr"><div>## Proposed solution</div><div><br></div><div>Add syntax to describe a restricted set of cases from an enum. </div><div><br></div><div>```swift</div><div>typealias LCDColors = Colors.(red|green|blue)</div><div>```</div><div><br></div><div>`LCDColors ` has all of the type and instance methods of `Colors`. Cases must appear in the same order as their original declaration. </div><div><br></div><div><br></div><div>## Detailed design</div><div><br></div><div>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. </div><div><br></div><div>## Impact on existing code</div><div><br></div><div>This is an additive change which should have no breaking change to existing code.</div><div><br></div><div><br></div></div></div></div>
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></blockquote></div><br></div>
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div>