<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="">I really like this idea, a few comments I have:</div><div class=""><ul class=""><li class="">Would this subset be exhaustive within only the subset you’ve restricted it to? I’m hoping so! i.e- if I do a switch on LCDColors I assume I only have to provide three cases, but this doesn’t appear to be expressly mentioned.</li><li class="">Do you envision this being usable in function signatures without declaring a type alias first? I can see cases where it may be convenient to do so, but some of the concerns with ad-hoc enums has been over there being no formal declaration of the type.</li><li class="">Lastly, is the ordering of the labels really important? Can’t the compiler just reorder them behind the scenes if necessary? I don’t think there should be any problem with the compiler detecting that Colors.(violet|orange|green) is the same as Colors.(orange|green|violet). I mean it’d be good practice to maintain the same order of course, but I think it’s better to allow any order, as the parent type’s ordering may change and break stuff; I’m not sure if relying on the parent’s ordering is really wise anyway, if you need it for some purpose then it should be defined in a method.</li><li class="">You need to cover conversion between the two types. I assume that if I have an LCDColors case it will work anywhere that takes a case from Colors, but how does the reverse work? Can I assign an instance of Colors to LCDColors via casting for example (with a failure if it’s not one of the specified cases)?</li></ul></div><div class="">But yeah, I like this idea, it’s kind of like an enum “slice”, and while it’s not strictly the same as ad-hoc enums it could solve many of their use-cases in a safer way.</div><br class=""><div><blockquote type="cite" class=""><div class="">On 3 Jun 2016, at 14:22, T.J. Usiyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><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" 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 class="" style="white-space:pre"> </span>case red, orange, yellow, green, blue, indigo, violet</div><div class=""><span class="" style="white-space:pre"> </span>…</div><div class="">}</div><div class=""><br class=""></div><div class="">enum LCDColors {</div><div class=""><span class="" style="white-space:pre"> </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 </div><div class=""><span class="" style="white-space:pre"> </span>1. Duplicate functionality in `LCDColors` </div><div class=""><span class="" style="white-space:pre"> </span>- Completely manually</div><div class=""><span class="" style="white-space:pre"> </span>- Protocols with 'minimal' manual duplication</div><div class=""><span class="" style="white-space:pre"> </span>2. Avoid duplication by allowing conversion to `Colors`. </div><div class=""><br class=""></div><div class="">Neither of these solutions make the subset relationship between `Colors` and `LCDColors` clear or strict.</div><div class=""><br class=""></div><div class="">## Proposed solution</div><div class=""><br class=""></div><div class="">Add syntax to describe a restricted set of cases from an enum. </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. </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. </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>
_______________________________________________<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>