<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="">A few ideas:</div><div class=""><br class=""></div><div class="">* Mention the pull request about member sets?</div><div class="">* I'd try to give some more compelling use cases (Where a union type can be broadly applied across more specific uses, which then tend to narrow the applicable cases, and you want to limit (and compile check) those cases while inheriting behavior).</div><div class="">* Mention how enum specialization tends to limit possible cases, and consider how enum expansion/inheritance might be another direction for expanding existing enums (for example, when adding new phone models, but using an existing enum, with an extension), and how this might impact footprint in associated types.</div><div class="">* Discuss how behavior extensions on narrowed enums could be limited to the subset, so would be syntactically limited to the semantic subset as a motivation for why LCD colors might appropriately be used in a calibrate functions but the full color cases would not, etc.</div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 3, 2016, at 3:35 PM, 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="">Since this seems to have some interest, I've made a gist.<div class=""><br class=""></div><div class=""><a href="https://gist.github.com/griotspeak/963bc87a0c244c120264b11fb022d78c" class="">https://gist.github.com/griotspeak/963bc87a0c244c120264b11fb022d78c</a></div><div class=""><h2 id="introduction" style="color:rgb(17,17,17);font-size:27px;line-height:42px;margin-top:42px;margin-bottom:21px;font-family:'Helvetica Neue',Helvetica,Arial,Verdana,sans-serif" class="">Introduction</h2><p style="color:rgb(17,17,17);font-family:'Helvetica Neue',Helvetica,Arial,Verdana,sans-serif;word-wrap:break-word;margin:1.3125em 0px;font-size:1.1429em;line-height:1.3125em" class="">This proposal adds/creates syntax to allow ad hoc creation of enums whose members are strict subsets of explicitly defined enums.</p><p style="color:rgb(17,17,17);font-family:'Helvetica Neue',Helvetica,Arial,Verdana,sans-serif;word-wrap:break-word;margin:1.3125em 0px;font-size:1.1429em;line-height:1.3125em" class="">Swift-evolution thread: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/020025.html" style="color:rgb(13,110,161);text-decoration:none" class=""><ins id="firstdiff" style="display:inline-block;text-decoration:none!important;border:none!important;background-image:none!important" class=""></ins>Discussion thread topic for that proposal</a></p><h2 id="motivation" style="color:rgb(17,17,17);font-size:27px;line-height:42px;margin-top:42px;margin-bottom:21px;font-family:'Helvetica Neue',Helvetica,Arial,Verdana,sans-serif" class="">Motivation</h2><p style="color:rgb(17,17,17);font-family:'Helvetica Neue',Helvetica,Arial,Verdana,sans-serif;word-wrap:break-word;margin:1.3125em 0px;font-size:1.1429em;line-height:1.3125em" class="">Consider a situation where we have an enum <code style="line-height:1" class="">Color</code> which represents the entire set of colors relevant to your application with many salient methods and operations. We have also declared an enum <code style="line-height:1" class="">LCDColorModel</code> with only three colors, <code style="line-height:1" class="">red, blue, green</code> .</p><pre style="margin-top:21px;margin-bottom:21px;color:rgb(17,17,17);font-size:15px;height:183px;background-color:rgb(248,248,248)" class=""><code class="" style="line-height:inherit;display:block;padding:0.5em;color:rgb(51,51,51);height:auto"><span class=""><span class="" style="font-weight:bold">enum</span> <span class="" style="color:rgb(68,85,136);font-weight:bold">Color</span> </span>{
<span class="" style="font-weight:bold">case</span> red, orange, yellow, green, blue, indigo, violet
…
}
<span class=""><span class="" style="font-weight:bold">enum</span> <span class="" style="color:rgb(68,85,136);font-weight:bold">LCDColor</span> </span>{
<span class="" style="font-weight:bold">case</span> red, green, blue
}</code></pre><p style="color:rgb(17,17,17);font-family:'Helvetica Neue',Helvetica,Arial,Verdana,sans-serif;word-wrap:break-word;margin:1.3125em 0px;font-size:1.1429em;line-height:1.3125em" class="">The cases in <code style="line-height:1" class="">LCDColor</code> in our scenario do not require different behavior from their similarly named cases in <code style="line-height:1" class="">Color</code>. We would like, simply stated, to explicitly restrict the cases allowed within a specific portion of our software. There are, currently, a few approaches<br class="">1. Duplicate functionality in <code style="line-height:1" class="">LCDColor</code><br class="">- Completely manually<br class="">- Protocols with ‘minimal’ manual duplication<br class="">2. Avoid duplication by allowing conversion to <code style="line-height:1" class="">Color</code>. </p><p style="color:rgb(17,17,17);font-family:'Helvetica Neue',Helvetica,Arial,Verdana,sans-serif;word-wrap:break-word;margin:1.3125em 0px;font-size:1.1429em;line-height:1.3125em" class="">Neither of these solutions make the subset relationship between <code style="line-height:1" class="">Color</code> and <code style="line-height:1" class="">LCDColor</code> clear or strict.</p><h2 id="proposedsolution" style="color:rgb(17,17,17);font-size:27px;line-height:42px;margin-top:42px;margin-bottom:21px;font-family:'Helvetica Neue',Helvetica,Arial,Verdana,sans-serif" class="">Proposed solution</h2><p style="color:rgb(17,17,17);font-family:'Helvetica Neue',Helvetica,Arial,Verdana,sans-serif;word-wrap:break-word;margin:1.3125em 0px;font-size:1.1429em;line-height:1.3125em" class="">Add syntax to describe a restricted set of cases from an enum. </p><pre style="margin-top:21px;margin-bottom:21px;color:rgb(17,17,17);font-size:15px;height:36px;background-color:rgb(248,248,248)" class=""><code class="" style="line-height:inherit;display:block;padding:0.5em;color:rgb(51,51,51);height:auto"><span class="" style="font-weight:bold">typealias</span> <span class="">LCDColor</span> = <span class="">Color</span>.(red|green|blue)</code></pre><p style="color:rgb(17,17,17);font-family:'Helvetica Neue',Helvetica,Arial,Verdana,sans-serif;word-wrap:break-word;margin:1.3125em 0px;font-size:1.1429em;line-height:1.3125em" class=""><code style="line-height:1" class="">LCDColor</code> has all of the type and instance methods of <code style="line-height:1" class="">Color</code>.</p><ul style="margin-top:21px;margin-bottom:21px;padding-left:1.5em;color:rgb(17,17,17);font-family:'Helvetica Neue',Helvetica,Arial,Verdana,sans-serif;font-size:15px" class=""><li style="font-size:17px" class="">Barring any technical reason, the ‘actual’ name of the type, in this example, is <code style="line-height:1" class="">Color.(red|green|blue)</code> This makes the relationship to <code style="line-height:1" class="">Color</code>syntactically clear. If a typealias is not desired, <code style="line-height:1" class="">Color.(red|green|blue)</code> should refer to the same type as <code style="line-height:1" class="">LCDColor</code></li><li style="font-size:17px" class="">Switching over <code style="line-height:1" class="">Color.(red|green|blue)</code> should only need to be exhaustive for the three cases <code style="line-height:1" class="">.red</code>, <code style="line-height:1" class="">.green</code>, and <code style="line-height:1" class="">.blue</code>.</li><li style="font-size:17px" class="">Two initializers should be implicitly created<ul style="margin-top:0px;margin-bottom:0.4em;padding-left:1.5em" class=""><li class=""><code style="line-height:1" class="">Color</code> to <code style="line-height:1" class="">LCDColor?</code><ul style="margin-top:0px;margin-bottom:0.4em;padding-left:1.5em" class=""><li class="">returns nil for all cases not in <code style="line-height:1" class="">LCDColor</code></li></ul></li><li class=""><code style="line-height:1" class="">LCDColor</code> to <code style="line-height:1" class="">Color</code><ul style="margin-top:0px;margin-bottom:0.4em;padding-left:1.5em" class=""><li class="">Obvious and trivial implementation mapping cases from <code style="line-height:1" class="">LCDColor</code> to <code style="line-height:1" class="">Color</code></li></ul></li></ul></li><li style="font-size:17px" class="">Casting should be allowed<ul style="margin-top:0px;margin-bottom:0.4em;padding-left:1.5em" class=""><li class="">from superset to subset only using <code style="line-height:1" class="">as?</code> or <code style="line-height:1" class="">as!</code> syntax.</li><li class="">from subset to superset using <code style="line-height:1" class="">as</code></li></ul></li><li style="font-size:17px" class="">Creating subsets of subsets is not allowed but reasonable conversions among subsets should be allowed if technically feasible such that:<ul style="margin-top:0px;margin-bottom:0.4em;padding-left:1.5em" class=""><li class="">Given subsets of <code style="line-height:1" class="">C</code> <code style="line-height:1" class="">A</code> and <code style="line-height:1" class="">B</code>, where A is a superset of B, the casting relationship between <code style="line-height:1" class="">A</code> and <code style="line-height:1" class="">B</code> should be similar to that between <code style="line-height:1" class="">C</code> and either of the other two named subsets.</li></ul></li></ul><h2 id="detaileddesign" style="color:rgb(17,17,17);font-size:27px;line-height:42px;margin-top:42px;margin-bottom:21px;font-family:'Helvetica Neue',Helvetica,Arial,Verdana,sans-serif" class="">Detailed design</h2><p style="color:rgb(17,17,17);font-family:'Helvetica Neue',Helvetica,Arial,Verdana,sans-serif;word-wrap:break-word;margin:1.3125em 0px;font-size:1.1429em;line-height:1.3125em" 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.<br class="">If a mangled name approach is taken, the ordering of cases should be sorted to ensure stability.</p><h2 id="alternativesconsidered" style="color:rgb(17,17,17);font-size:27px;line-height:42px;margin-top:42px;margin-bottom:21px;font-family:'Helvetica Neue',Helvetica,Arial,Verdana,sans-serif" class="">Alternatives considered</h2><ul style="margin-top:21px;margin-bottom:21px;padding-left:1.5em;color:rgb(17,17,17);font-family:'Helvetica Neue',Helvetica,Arial,Verdana,sans-serif;font-size:15px" class=""><li style="font-size:17px" class="">Do nothing. This feature is not strictly necessary but does allow for expressivity not currently available in the language.</li><li style="font-size:17px" class="">implicitly create properties which convert to superset type.</li></ul><h2 id="impactonexistingcode" style="color:rgb(17,17,17);font-size:27px;line-height:42px;margin-top:42px;margin-bottom:21px;font-family:'Helvetica Neue',Helvetica,Arial,Verdana,sans-serif" class="">Impact on existing code</h2><p style="color:rgb(17,17,17);font-family:'Helvetica Neue',Helvetica,Arial,Verdana,sans-serif;word-wrap:break-word;margin:1.3125em 0px;font-size:1.1429em;line-height:1.3125em" class="">This is an additive change which should have no breaking change to existing code.</p></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jun 3, 2016 at 4:57 PM, Austin Zheng <span dir="ltr" class=""><<a href="mailto:austinzheng@gmail.com" target="_blank" class="">austinzheng@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">I really like the idea behind this proposal.<div class=""><br class=""></div><div class="">Some questions:</div><div class=""><br class=""></div><div class="">- Would the enum 'slice' be a distinct type relative to the base enum?</div><div class="">- On a related note, would shared cases between the sliced enum and the base enum be implicitly convertible?</div><div class="">- 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)/</div><div class="">- 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?</div><div class="">- If the parent enum has members that switch on 'self', would those members be available to the child automatically?</div><div class="">- 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'?</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Austin</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote"><div class=""><div class="h5">On Fri, Jun 3, 2016 at 6:22 AM, T.J. Usiyan via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><div class="h5"><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 </div><div class=""><span style="white-space:pre-wrap" class=""> </span>1. Duplicate functionality in `LCDColors` </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`. </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=""></div></div><span class="">_______________________________________________<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" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></span></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>