<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Your original syntax makes &nbsp;LCDColors clearly a type. The typealias obscures the fact that a new type is being created. An alternative might be something like:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">```</div><div class="">enum LCDColors : Colors {</div></div><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>case red, green, blue</div></div><div class=""><div class="">}</div></div><div class=""><div class="">```</div></div></blockquote><div class=""><br class=""></div><div class="">or perhaps</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">```</div><div class="">enum LCDColors subset: Colors {</div></div><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>case red, green, blue</div></div><div class=""><div class="">}</div></div><div class=""><div class="">```</div></div></blockquote><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">```</div><div class="">enum AppErrors &nbsp;{</div></div><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>// Defined by its subsets</div></div><div class=""><div class="">}</div></div><div class=""><div class=""><br class=""></div></div><div class=""><div class="">enum NetworkingErrors&nbsp;&nbsp;subset:&nbsp;AppErrors&nbsp;{</div></div><div class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>case NWError1 = 1000, NWError2. NWError3</div></div></div><div class=""><div class=""><div class="">}</div></div></div><div class=""><div class=""><br class="Apple-interchange-newline"></div></div><div class=""><div class="">&nbsp;</div></div><div class=""><div class="">enum UserInputErrors&nbsp;&nbsp;subset:&nbsp;AppErrors&nbsp;{</div></div><div class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>case UIError1 = 2000, UIError2. UIError3</div></div></div><div class=""><div class=""><div class="">}</div></div></div><div class=""><div class="">&nbsp;```</div></div></blockquote><div class="">The compiler would have to check for rawValue collisions.</div><div class=""><br class=""></div><div class="">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;" class=""><div class=""><br class=""></div><div class="">&nbsp;```</div><div class="">enum AppErrors &nbsp;{</div><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>// Defined by its subsets</div></div><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>case NetworkingErrorBase = 1000</div></div><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>case UIErrorBase = 2000</div></div><div class=""><div class="">}</div></div><div class=""><div class=""><br class=""></div></div><div class=""><div class="">enum NetworkingErrors&nbsp;&nbsp;subset:&nbsp;AppErrors&nbsp;{</div></div><div class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>case NWError1 = NetworkingErrorBase, NWError2. NWError3</div></div></div><div class=""><div class=""><div class="">}</div></div></div><div class=""><div class=""><br class="Apple-interchange-newline"></div></div><div class=""><div class="">enum UserInputErrors&nbsp;&nbsp;subset:&nbsp;AppErrors&nbsp;{</div></div><div class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>case UIError1 =&nbsp;UIErrorBase, UIError2. UIError3</div></div></div><div class=""><div class=""><div class="">}</div></div></div><div class=""><div class="">&nbsp;```</div></div></blockquote><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 3, 2016, at 10:39 AM, T.J. Usiyan via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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 class=""><br class=""><div class="">TJ</div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jun 3, 2016 at 12:32 PM, Christopher Kornher <span dir="ltr" class="">&lt;<a href="mailto:ckornher@me.com" target="_blank" class="">ckornher@me.com</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">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 class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><span class="">``` swift<br class="">enum Colors {<br class=""><span style="white-space:pre-wrap" class="">        </span>case red, orange, yellow, green, blue, indigo, violet<br class=""><span style="white-space:pre-wrap" class="">        </span>…<br class="">}<br class=""><font color="#5856d6" class=""><br class=""></font></span>extension&nbsp;Colors&nbsp;{<br class=""><span style="white-space:pre-wrap" class="">        </span>subset &nbsp;LCDColors &nbsp;red, green, blue</div><div class="">}<br class=""><div dir="ltr" class=""><div class="">```</div></div></div><div class=""><div dir="ltr" class=""><div class=""><br class=""></div></div></div><div class=""><div class=""><div class="h5"><blockquote type="cite" class=""><div class="">On Jun 3, 2016, at 7:22 AM, T.J. Usiyan via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class="">This is loosely related to but not meant to 'compete' with the ad hoc enum proposal.</div><div class=""><br class=""></div><div class="">## Introduction</div><div class=""><br class=""></div><div class="">This proposal adds/creates syntax to allow ad hoc creation of enums whose members are strict subsets of explicitly defined enums.</div><div class=""><br class=""></div><div class="">Swift-evolution thread: [Discussion thread topic for that proposal](<a href="http://news.gmane.org/gmane.comp.lang.swift.evolution" target="_blank" class="">http://news.gmane.org/gmane.comp.lang.swift.evolution</a>)</div><div class=""><br class=""></div><div class="">## Motivation</div><div class="">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 class=""><br class=""></div><div class="">``` swift</div><div class="">enum Colors {</div><div class=""><span style="white-space:pre-wrap" class="">        </span>case red, orange, yellow, green, blue, indigo, violet</div><div class=""><span style="white-space:pre-wrap" class="">        </span>…</div><div class="">}</div><div class=""><br class=""></div><div class="">enum LCDColors {</div><div class=""><span style="white-space:pre-wrap" class="">        </span>case red, green, blue</div><div class="">}</div><div class="">```</div><div class=""><br class=""></div><div class="">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&nbsp;</div><div class=""><span style="white-space:pre-wrap" class="">        </span>1. Duplicate functionality in `LCDColors`&nbsp;</div><div class=""><span style="white-space:pre-wrap" class="">                </span>- Completely manually</div><div class=""><span style="white-space:pre-wrap" class="">                </span>- Protocols with 'minimal' manual duplication</div><div class=""><span style="white-space:pre-wrap" class="">        </span>2. Avoid duplication by allowing conversion to `Colors`.&nbsp;</div><div class=""><br class=""></div><div class="">Neither of these solutions make the subset relationship between `Colors` and `LCDColors` &nbsp;clear or strict.</div></div></div></blockquote><div class=""><br class=""></div></div></div><blockquote type="cite" class=""><div class=""><div class=""><div class="h5"><div dir="ltr" class=""><div class="">## Proposed solution</div><div class=""><br class=""></div><div class="">Add syntax to describe a restricted set of cases from an enum.&nbsp;</div><div class=""><br class=""></div><div class="">```swift</div><div class="">typealias LCDColors = Colors.(red|green|blue)</div><div class="">```</div><div class=""><br class=""></div><div class="">`LCDColors ` has all of the type and instance methods of `Colors`. Cases must appear in the same order as their original declaration.&nbsp;</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">## Detailed design</div><div class=""><br class=""></div><div class="">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.&nbsp;</div><div class=""><br class=""></div><div class="">## Impact on existing code</div><div class=""><br class=""></div><div class="">This is an additive change which should have no breaking change to existing code.</div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>