# \[Proposal\] Enum subsets

**URL:** <https://forums.swift.org/t/proposal-enum-subsets/2869>\
**Category:** Discussion\
**Created:** [June 3, 2016, 1:22pm UTC](https://forums.swift.org/t/proposal-enum-subsets/2869 "2016-06-03T13:22:23Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![griotspeak](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/griotspeak/32/1966_2.png) [@griotspeak](https://forums.swift.org/u/griotspeak)\
**Post date:** [June 3, 2016, 1:22pm UTC](https://forums.swift.org/t/proposal-enum-subsets/2869/1 "2016-06-03T13:22:23Z")

</div>

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\](http://news.gmane.org/gmane.comp.lang.swift.evolution%5C))

## 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.

---

<div class="post-metadata">

**Author:** ![Christopher\_Kornher1](https://avatars.discourse-cdn.com/v4/letter/c/3da27b/32.png) [@Christopher\_Kornher1](https://forums.swift.org/u/Christopher_Kornher1)\
**Post date:** [June 3, 2016, 4:32pm UTC](https://forums.swift.org/t/proposal-enum-subsets/2869/2 "2016-06-03T16:32:25Z")

</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.

```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 \<swift-evolution@swift.org\> 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\](http://news.gmane.org/gmane.comp.lang.swift.evolution%5C))
> > 
> > ## 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  
> > &nbsp;&nbsp;1. Duplicate functionality in `LCDColors`  
> > &nbsp;&nbsp;&nbsp;&nbsp;- Completely manually  
> > &nbsp;&nbsp;&nbsp;&nbsp;- Protocols with 'minimal' manual duplication  
> > &nbsp;&nbsp;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  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Austin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/austin/32/1196_2.png) [@Austin](https://forums.swift.org/u/Austin)\
**Post date:** [June 3, 2016, 8:57pm UTC](https://forums.swift.org/t/proposal-enum-subsets/2869/3 "2016-06-03T20:57:39Z")

</div>

I really like the idea behind this proposal.

Some questions:

- Would the enum 'slice' be a distinct type relative to the base enum?  
- On a related note, would shared cases between the sliced enum and the  
base enum be implicitly convertible?  
- 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)/  
- 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?  
- If the parent enum has members that switch on 'self', would those members  
be available to the child automatically?  
- 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'?

Best,  
Austin

> **···**
>
> On Fri, Jun 3, 2016 at 6:22 AM, T.J. Usiyan via swift-evolution \< swift-evolution@swift.org\> 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\](http://news.gmane.org/gmane.comp.lang.swift.evolution%5C))
> > 
> > ## 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  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Haravikk3](https://avatars.discourse-cdn.com/v4/letter/h/df705f/32.png) [@Haravikk3](https://forums.swift.org/u/Haravikk3)\
**Post date:** [June 3, 2016, 8:44pm UTC](https://forums.swift.org/t/proposal-enum-subsets/2869/4 "2016-06-03T20:44:58Z")

</div>

I really like this idea, a few comments I have:  
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.  
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.  
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.  
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)?  
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.

> **···**
>
> > On 3 Jun 2016, at 14:22, T.J. Usiyan via swift-evolution \<swift-evolution@swift.org\> 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\](http://news.gmane.org/gmane.comp.lang.swift.evolution%5C))
> > 
> > ## 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  
> > &nbsp;&nbsp;1. Duplicate functionality in `LCDColors`  
> > &nbsp;&nbsp;&nbsp;&nbsp;- Completely manually  
> > &nbsp;&nbsp;&nbsp;&nbsp;- Protocols with 'minimal' manual duplication  
> > &nbsp;&nbsp;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  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![griotspeak](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/griotspeak/32/1966_2.png) [@griotspeak](https://forums.swift.org/u/griotspeak)\
**Post date:** [June 3, 2016, 4:39pm UTC](https://forums.swift.org/t/proposal-enum-subsets/2869/5 "2016-06-03T16:39:57Z")

</div>

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 \<ckornher@me.com\> 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 \< \> swift-evolution@swift.org\> 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\](http://news.gmane.org/gmane.comp.lang.swift.evolution%5C))
> > 
> > ## 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  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![griotspeak](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/griotspeak/32/1966_2.png) [@griotspeak](https://forums.swift.org/u/griotspeak)\
**Post date:** [June 3, 2016, 9:35pm UTC](https://forums.swift.org/t/proposal-enum-subsets/2869/6 "2016-06-03T21:35:09Z")

</div>

Since this seems to have some interest, I've made a gist.

> <https://gist.github.com/griotspeak/963bc87a0c244c120264b11fb022d78c>

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  
\<[https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/020025.html&gt](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/020025.html&gt);  
Motivation

Consider a situation where we have an enum Color 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 .

enum Color {  
&nbsp;&nbsp;&nbsp;&nbsp;case red, orange, yellow, green, blue, indigo, violet  
&nbsp;&nbsp;&nbsp;&nbsp;…  
}  
enum LCDColor {  
&nbsp;&nbsp;&nbsp;&nbsp;case red, green, blue  
}

The cases in LCDColor in our scenario do not require different behavior  
from their similarly named cases in Color. 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 LCDColor  
- Completely manually  
- Protocols with ‘minimal’ manual duplication  
2. Avoid duplication by allowing conversion to Color.

Neither of these solutions make the subset relationship between Color and  
LCDColor clear or strict.  
Proposed solution

Add syntax to describe a restricted set of cases from an enum.

typealias LCDColor = Color.(red|green|blue)

LCDColor has all of the type and instance methods of Color.

&nbsp;&nbsp;&nbsp;- Barring any technical reason, the ‘actual’ name of the type, in this  
&nbsp;&nbsp;&nbsp;example, is Color.(red|green|blue) This makes the relationship to  
Colorsyntactically  
&nbsp;&nbsp;&nbsp;clear. If a typealias is not desired, Color.(red|green|blue) should  
&nbsp;&nbsp;&nbsp;refer to the same type as LCDColor  
&nbsp;&nbsp;&nbsp;- Switching over Color.(red|green|blue) should only need to be  
&nbsp;&nbsp;&nbsp;exhaustive for the three cases .red, .green, and .blue.  
&nbsp;&nbsp;&nbsp;- Two initializers should be implicitly created  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- Color to LCDColor?  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- returns nil for all cases not in LCDColor  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- LCDColor to Color  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- Obvious and trivial implementation mapping cases from LCDColor  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;to Color  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- Casting should be allowed  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- from superset to subset only using as? or as! syntax.  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- from subset to superset using as  
&nbsp;&nbsp;&nbsp;- Creating subsets of subsets is not allowed but reasonable conversions  
&nbsp;&nbsp;&nbsp;among subsets should be allowed if technically feasible such that:  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- Given subsets of C A and B, where A is a superset of B, the casting  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;relationship between A and B should be similar to that between C and  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;either of the other two named subsets.

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.  
If a mangled name approach is taken, the ordering of cases should be sorted  
to ensure stability.  
Alternatives considered

&nbsp;&nbsp;&nbsp;- Do nothing. This feature is not strictly necessary but does allow for  
&nbsp;&nbsp;&nbsp;expressivity not currently available in the language.  
&nbsp;&nbsp;&nbsp;- implicitly create properties which convert to superset type.

Impact on existing code

This is an additive change which should have no breaking change to existing  
code.

> **···**
>
> On Fri, Jun 3, 2016 at 4:57 PM, Austin Zheng \<austinzheng@gmail.com\> wrote:
> 
> > I really like the idea behind this proposal.
> > 
> > Some questions:
> > 
> > - Would the enum 'slice' be a distinct type relative to the base enum?  
> > - On a related note, would shared cases between the sliced enum and the  
> > base enum be implicitly convertible?  
> > - 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)/  
> > - 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?  
> > - If the parent enum has members that switch on 'self', would those  
> > members be available to the child automatically?  
> > - 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'?
> > 
> > Best,  
> > Austin
> > 
> > On Fri, Jun 3, 2016 at 6:22 AM, T.J. Usiyan via swift-evolution \< \> swift-evolution@swift.org\> 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\](http://news.gmane.org/gmane.comp.lang.swift.evolution%5C))
> > > 
> > > ## 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  
> > > swift-evolution@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Christopher\_Kornher1](https://avatars.discourse-cdn.com/v4/letter/c/3da27b/32.png) [@Christopher\_Kornher1](https://forums.swift.org/u/Christopher_Kornher1)\
**Post date:** [June 3, 2016, 7:56pm UTC](https://forums.swift.org/t/proposal-enum-subsets/2869/7 "2016-06-03T19:56:06Z")

</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:

```swift
enum LCDColors : Colors {
	case red, green, blue
}

```

or perhaps

```swift
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:

```swift
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:

```swift
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 \<swift-evolution@swift.org\> 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 \<ckornher@me.com \<mailto:ckornher@me.com\>\> 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 \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> 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\](http://news.gmane.org/gmane.comp.lang.swift.evolution%5C))
> > > 
> > > ## 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  
> > > &nbsp;&nbsp;1. Duplicate functionality in `LCDColors`  
> > > &nbsp;&nbsp;&nbsp;&nbsp;- Completely manually  
> > > &nbsp;&nbsp;&nbsp;&nbsp;- Protocols with 'minimal' manual duplication  
> > > &nbsp;&nbsp;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  
> > > swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Erica\_Sadun](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/erica_sadun/32/243_2.png) [@Erica\_Sadun](https://forums.swift.org/u/Erica_Sadun)\
**Post date:** [June 3, 2016, 9:41pm UTC](https://forums.swift.org/t/proposal-enum-subsets/2869/8 "2016-06-03T21:41:56Z")

</div>

A few ideas:

\* Mention the pull request about member sets?  
\* 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).  
\* 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.  
\* 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.

-- E

> **···**
>
> > On Jun 3, 2016, at 3:35 PM, T.J. Usiyan via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > Since this seems to have some interest, I've made a gist.
> > 
> > [Enum Subsets · GitHub](https://gist.github.com/griotspeak/963bc87a0c244c120264b11fb022d78c)  
> > 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 \<[https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/020025.html&gt](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/020025.html&gt);  
> > Motivation
> > 
> > Consider a situation where we have an enum Color 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 .
> > 
> > enum Color {  
> > &nbsp;&nbsp;&nbsp;&nbsp;case red, orange, yellow, green, blue, indigo, violet  
> > &nbsp;&nbsp;&nbsp;&nbsp;…  
> > }
> > 
> > enum LCDColor {  
> > &nbsp;&nbsp;&nbsp;&nbsp;case red, green, blue  
> > }  
> > The cases in LCDColor in our scenario do not require different behavior from their similarly named cases in Color. 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 LCDColor  
> > - Completely manually  
> > - Protocols with ‘minimal’ manual duplication  
> > 2. Avoid duplication by allowing conversion to Color.
> > 
> > Neither of these solutions make the subset relationship between Color and LCDColor clear or strict.
> > 
> > Proposed solution
> > 
> > Add syntax to describe a restricted set of cases from an enum.
> > 
> > typealias LCDColor = Color.(red|green|blue)  
> > LCDColor has all of the type and instance methods of Color.
> > 
> > Barring any technical reason, the ‘actual’ name of the type, in this example, is Color.(red|green|blue) This makes the relationship to Colorsyntactically clear. If a typealias is not desired, Color.(red|green|blue) should refer to the same type as LCDColor  
> > Switching over Color.(red|green|blue) should only need to be exhaustive for the three cases .red, .green, and .blue.  
> > Two initializers should be implicitly created  
> > Color to LCDColor?  
> > returns nil for all cases not in LCDColor  
> > LCDColor to Color  
> > Obvious and trivial implementation mapping cases from LCDColor to Color  
> > Casting should be allowed  
> > from superset to subset only using as? or as! syntax.  
> > from subset to superset using as  
> > Creating subsets of subsets is not allowed but reasonable conversions among subsets should be allowed if technically feasible such that:  
> > Given subsets of C A and B, where A is a superset of B, the casting relationship between A and B should be similar to that between C and either of the other two named subsets.  
> > 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.  
> > If a mangled name approach is taken, the ordering of cases should be sorted to ensure stability.
> > 
> > Alternatives considered
> > 
> > Do nothing. This feature is not strictly necessary but does allow for expressivity not currently available in the language.  
> > implicitly create properties which convert to superset type.  
> > Impact on existing code
> > 
> > This is an additive change which should have no breaking change to existing code.
> > 
> > On Fri, Jun 3, 2016 at 4:57 PM, Austin Zheng \<austinzheng@gmail.com \<mailto:austinzheng@gmail.com\>\> wrote:  
> > I really like the idea behind this proposal.
> > 
> > Some questions:
> > 
> > - Would the enum 'slice' be a distinct type relative to the base enum?  
> > - On a related note, would shared cases between the sliced enum and the base enum be implicitly convertible?  
> > - 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)/  
> > - 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?  
> > - If the parent enum has members that switch on 'self', would those members be available to the child automatically?  
> > - 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'?
> > 
> > Best,  
> > Austin
> > 
> > On Fri, Jun 3, 2016 at 6:22 AM, T.J. Usiyan via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> 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\](http://news.gmane.org/gmane.comp.lang.swift.evolution%5C))
> > 
> > ## 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  
> > &nbsp;&nbsp;1. Duplicate functionality in `LCDColors`  
> > &nbsp;&nbsp;&nbsp;&nbsp;- Completely manually  
> > &nbsp;&nbsp;&nbsp;&nbsp;- Protocols with 'minimal' manual duplication  
> > &nbsp;&nbsp;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  
> > swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Tony\_Allevato](https://avatars.discourse-cdn.com/v4/letter/t/f1d935/32.png) [@Tony\_Allevato](https://forums.swift.org/u/Tony_Allevato)\
**Post date:** [June 3, 2016, 10:02pm UTC](https://forums.swift.org/t/proposal-enum-subsets/2869/9 "2016-06-03T22:02:27Z")

</div>

I like the idea, conceptually—having more set-like semantics for enums  
sounds like it would open up some interesting possibilities. (And I don't  
think we should limit ourselves to subsets either. Supersets are also  
interesting.)

Things could get pretty tricky though, so there are a lot of gaps to fill  
in here. Off the top of my head, I'd be curious about the following  
situations:

\* You don't mention cases with associated values anywhere. Is it your  
intention to prohibit those, or would the following work?

enum Foo {  
&nbsp;&nbsp;&nbsp;case Bar  
&nbsp;&nbsp;&nbsp;case Baz(Int)  
&nbsp;&nbsp;&nbsp;case Blorp(String)  
}  
typealias FooSubset = Foo.(Bar|Baz)  
// FooSubset is effectively: enum FooSubset { case Bar; case Baz(Int) }?

I can't think of any reason off the top of my head to prohibit cases with  
associated values, for what it's worth.

\* How would non-case members of an enum (i.e., computed properties,  
methods, etc.) be effected? Other folks in the thread have mentioned  
methods that switch on self. In a very abstract sense, there are two kinds  
of these properties/methods: those that simply use "self" to branch, and  
those that use the enum in other ways. For example, I see no reason that  
this shouldn't work:

enum Color {  
&nbsp;&nbsp;case red  
&nbsp;&nbsp;case blue  
&nbsp;&nbsp;case green

&nbsp;&nbsp;var uiColor: UIColor {  
&nbsp;&nbsp;&nbsp;&nbsp;switch self {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;case .red: return UIColor.red()  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;case .blue: return UIColor.blue()  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;case .green: return UIColor.green()  
&nbsp;&nbsp;&nbsp;&nbsp;}  
&nbsp;&nbsp;}  
}  
let x: Color.(blue|green) = Color.blue  
let color = x.uiColor

But on the other hand, you could have something like this:

enum Color {  
&nbsp;&nbsp;case red  
&nbsp;&nbsp;case blue  
&nbsp;&nbsp;case green

&nbsp;&nbsp;var nextColor: Color {  
&nbsp;&nbsp;&nbsp;&nbsp;switch self {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;case .red: return .blue  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;case .blue: return .green  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;case .green: return .red  
&nbsp;&nbsp;&nbsp;&nbsp;}  
&nbsp;&nbsp;}  
}  
let x: Color.(blue|green) = Color.blue  
let color = x.nextColor // umm....

Things start getting really hard to predict because it's very hard to  
reason about what happens inside these computed properties, and I fear that  
the solution becomes "conservatively exclude a lot of stuff" and that  
starts taking a lot of the power away from those enums.

> **···**
>
> On Fri, Jun 3, 2016 at 2:35 PM T.J. Usiyan via swift-evolution \< swift-evolution@swift.org\> wrote:
> 
> > Since this seems to have some interest, I've made a gist.
> > 
> > [Enum Subsets · GitHub](https://gist.github.com/griotspeak/963bc87a0c244c120264b11fb022d78c)  
> > 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  
> > \<[https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/020025.html&gt](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/020025.html&gt);  
> > Motivation
> > 
> > Consider a situation where we have an enum Color 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 .
> > 
> > enum Color {
> > 
> > case red, orange, yellow, green, blue, indigo, violet  
> > &nbsp;&nbsp;&nbsp;&nbsp;…  
> > }
> > 
> > enum LCDColor {  
> > &nbsp;&nbsp;&nbsp;&nbsp;case red, green, blue  
> > }
> > 
> > The cases in LCDColor in our scenario do not require different behavior  
> > from their similarly named cases in Color. 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 LCDColor
> > 
> > - Completely manually  
> > - Protocols with ‘minimal’ manual duplication
> > 
> > 2. Avoid duplication by allowing conversion to Color.
> > 
> > Neither of these solutions make the subset relationship between Color and  
> > LCDColor clear or strict.  
> > Proposed solution
> > 
> > Add syntax to describe a restricted set of cases from an enum.
> > 
> > typealias LCDColor = Color.(red|green|blue)
> > 
> > LCDColor has all of the type and instance methods of Color.
> > 
> > &nbsp;&nbsp;&nbsp;- Barring any technical reason, the ‘actual’ name of the type, in this  
> > &nbsp;&nbsp;&nbsp;example, is Color.(red|green|blue) This makes the relationship to Colorsyntactically  
> > &nbsp;&nbsp;&nbsp;clear. If a typealias is not desired, Color.(red|green|blue) should  
> > &nbsp;&nbsp;&nbsp;refer to the same type as LCDColor  
> > &nbsp;&nbsp;&nbsp;- Switching over Color.(red|green|blue) should only need to be  
> > &nbsp;&nbsp;&nbsp;exhaustive for the three cases .red, .green, and .blue.  
> > &nbsp;&nbsp;&nbsp;- Two initializers should be implicitly created  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- Color to LCDColor?  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- returns nil for all cases not in LCDColor  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- LCDColor to Color  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- Obvious and trivial implementation mapping cases from LCDColor  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;to Color  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- Casting should be allowed  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- from superset to subset only using as? or as! syntax.  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- from subset to superset using as  
> > &nbsp;&nbsp;&nbsp;- Creating subsets of subsets is not allowed but reasonable  
> > &nbsp;&nbsp;&nbsp;conversions among subsets should be allowed if technically feasible such  
> > &nbsp;&nbsp;&nbsp;that:  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- Given subsets of C A and B, where A is a superset of B, the  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;casting relationship between A and B should be similar to that  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;between C and either of the other two named subsets.
> > 
> > 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.
> > 
> > If a mangled name approach is taken, the ordering of cases should be  
> > sorted to ensure stability.  
> > Alternatives considered
> > 
> > &nbsp;&nbsp;&nbsp;- Do nothing. This feature is not strictly necessary but does allow  
> > &nbsp;&nbsp;&nbsp;for expressivity not currently available in the language.  
> > &nbsp;&nbsp;&nbsp;- implicitly create properties which convert to superset type.
> > 
> > Impact on existing code
> > 
> > This is an additive change which should have no breaking change to  
> > existing code.
> > 
> > On Fri, Jun 3, 2016 at 4:57 PM, Austin Zheng \<austinzheng@gmail.com\> \> wrote:
> > 
> > > I really like the idea behind this proposal.
> > > 
> > > Some questions:
> > > 
> > > - Would the enum 'slice' be a distinct type relative to the base enum?  
> > > - On a related note, would shared cases between the sliced enum and the  
> > > base enum be implicitly convertible?  
> > > - 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)/  
> > > - 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?  
> > > - If the parent enum has members that switch on 'self', would those  
> > > members be available to the child automatically?  
> > > - 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'?
> > > 
> > > Best,  
> > > Austin
> > > 
> > > On Fri, Jun 3, 2016 at 6:22 AM, T.J. Usiyan via swift-evolution \< \>\> swift-evolution@swift.org\> 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\](http://news.gmane.org/gmane.comp.lang.swift.evolution%5C))
> > > > 
> > > > ## 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  
> > > > swift-evolution@swift.org  
> > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Chris\_Lattner](https://avatars.discourse-cdn.com/v4/letter/c/bc8723/32.png) [@Chris\_Lattner](https://forums.swift.org/u/Chris_Lattner)\
**Post date:** [June 4, 2016, 5:25am UTC](https://forums.swift.org/t/proposal-enum-subsets/2869/10 "2016-06-04T05:25:35Z")

</div>

We have frequently discussed introducing subtype relationships between structs and enums, in an effort to allow limited implicit promotions (e.g. from small integers to wider integers). Wouldn’t that be a more general solution to this same problem?

-Chris

> **···**
>
> > On Jun 3, 2016, at 2:35 PM, T.J. Usiyan via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > Since this seems to have some interest, I've made a gist.
> > 
> > [Enum Subsets · GitHub](https://gist.github.com/griotspeak/963bc87a0c244c120264b11fb022d78c)

---

<div class="post-metadata">

**Author:** ![griotspeak](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/griotspeak/32/1966_2.png) [@griotspeak](https://forums.swift.org/u/griotspeak)\
**Post date:** [June 3, 2016, 8:18pm UTC](https://forums.swift.org/t/proposal-enum-subsets/2869/11 "2016-06-03T20:18:29Z")

</div>

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 \<ckornher@me.com\> 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:
> > 
> > ```swift
> > enum LCDColors : Colors {
> > case red, green, blue
> > }
> > 
> > ```
> > 
> > or perhaps
> > 
> > ```swift
> > 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:
> > 
> > ```swift
> > 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:
> > 
> > ```swift
> > 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 \< \> swift-evolution@swift.org\> 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 \<ckornher@me.com\> \> 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 \< \>\> swift-evolution@swift.org\> 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\](http://news.gmane.org/gmane.comp.lang.swift.evolution%5C))
> > > 
> > > ## 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  
> > > swift-evolution@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Austin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/austin/32/1196_2.png) [@Austin](https://forums.swift.org/u/Austin)\
**Post date:** [June 4, 2016, 5:34am UTC](https://forums.swift.org/t/proposal-enum-subsets/2869/12 "2016-06-04T05:34:13Z")

</div>

It seems like it would make sense to model enum subsets as a subtype relationship.

Is the core team planning on drawing up a structs/enums subtyping proposal later this year?

Austin

> **···**
>
> > On Jun 3, 2016, at 10:25 PM, Chris Lattner \<clattner@apple.com\> wrote:
> > 
> > > On Jun 3, 2016, at 2:35 PM, T.J. Usiyan via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > > 
> > > Since this seems to have some interest, I've made a gist.
> > > 
> > > [Enum Subsets · GitHub](https://gist.github.com/griotspeak/963bc87a0c244c120264b11fb022d78c)
> > 
> > We have frequently discussed introducing subtype relationships between structs and enums, in an effort to allow limited implicit promotions (e.g. from small integers to wider integers). Wouldn’t that be a more general solution to this same problem?
> > 
> > -Chris

---

<div class="post-metadata">

**Author:** ![griotspeak](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/griotspeak/32/1966_2.png) [@griotspeak](https://forums.swift.org/u/griotspeak)\
**Post date:** [June 4, 2016, 8:26pm UTC](https://forums.swift.org/t/proposal-enum-subsets/2869/13 "2016-06-04T20:26:31Z")

</div>

It could be a more general solution. I am unclear about what 'subtype  
relationships' means here though.

Are you talking a about what you allude to here?  
[https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151130/000525.html](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151130/000525.html)

The benefit of explicitly narrowing, in my opinion, is that there is no  
unnecessary cost to figuring out lookup. (Please correct me if I am  
mistaken.) Implicit promotions introduce uncertainty with regard to what a  
value is being treated as in any given moment. This uncertainty is worth it  
in many cases but I will suggest that it is not worth it when trying to  
deal with a narrower set of cases from an already established set. For  
example, in the graph/lattice situation, conversions must be written  
because there is no reasonable conversion that can be assumed. In this  
proposal, the conversion is obvious and trivial because the relationship is  
completely clear.

All of that said, I \*am\* unclear about what subtype relationships means so  
it may very well be a better solution. It certainly sounds like a more  
general solution but I am not convinced that that is an advantage when  
trying to deal with a strict subset.

TJ

> **···**
>
> On Sat, Jun 4, 2016 at 1:25 AM, Chris Lattner \<clattner@apple.com\> wrote:
> 
> > On Jun 3, 2016, at 2:35 PM, T.J. Usiyan via swift-evolution \< \> swift-evolution@swift.org\> wrote:
> > 
> > Since this seems to have some interest, I've made a gist.
> > 
> > [Enum Subsets · GitHub](https://gist.github.com/griotspeak/963bc87a0c244c120264b11fb022d78c)
> > 
> > We have frequently discussed introducing subtype relationships between  
> > structs and enums, in an effort to allow limited implicit promotions (e.g.  
> > from small integers to wider integers). Wouldn’t that be a more general  
> > solution to this same problem?
> > 
> > -Chris

---

<div class="post-metadata">

**Author:** ![Christopher\_Kornher1](https://avatars.discourse-cdn.com/v4/letter/c/3da27b/32.png) [@Christopher\_Kornher1](https://forums.swift.org/u/Christopher_Kornher1)\
**Post date:** [June 3, 2016, 9:47pm UTC](https://forums.swift.org/t/proposal-enum-subsets/2869/14 "2016-06-03T21:47:28Z")

</div>

The syntax I described here has a number of problems, among them being:  
&nbsp;&nbsp;1) Creating a supersets in the way described breaks down badly when the declarations exist within multiple modules.  
&nbsp;&nbsp;2) The empty enum declaration is currently illegal and probably should be  
&nbsp;&nbsp;3) The superset declaration contains no clue as to what it really is.  
&nbsp;&nbsp;4) Possibly the most commonly needed use case is not possible with this syntax: Extending enums defined in other modules

I believe that best solution is explicit ```subset:``` and ‘’’superset:``` relationships. They could be added to the language at the same time, or not, but it seems to make sense to consider the possibility of creating supersets along with creating subsets.

I will take more time to think this through before I reply again. It would be nice not to add a variation to ```:``` but that is the best syntax I could think of at the time.

> 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.

I agree.

> **···**
>
> > On Jun 3, 2016, at 2:18 PM, T.J. Usiyan via swift-evolution \<swift-evolution@swift.org\> wrote:
> 
> > 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 \<ckornher@me.com \<mailto:ckornher@me.com\>\> 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:
> > 
> > ```swift
> > enum LCDColors : Colors {
> > case red, green, blue
> > }
> > 
> > ```
> > 
> > or perhaps
> > 
> > ```swift
> > 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:
> > 
> > ```swift
> > 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:
> > 
> > ```swift
> > 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 \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> 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 \<ckornher@me.com \<mailto:ckornher@me.com\>\> 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 \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> 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\](http://news.gmane.org/gmane.comp.lang.swift.evolution%5C))
> > > > 
> > > > ## 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  
> > > > &nbsp;&nbsp;1. Duplicate functionality in `LCDColors`  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;- Completely manually  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;- Protocols with 'minimal' manual duplication  
> > > > &nbsp;&nbsp;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  
> > > > swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>  
> > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > > 
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\
**Post date:** [June 4, 2016, 12:00pm UTC](https://forums.swift.org/t/proposal-enum-subsets/2869/15 "2016-06-04T12:00:57Z")

</div>

> It seems like it would make sense to model enum subsets as a subtype relationship.
> 
> Is the core team planning on drawing up a structs/enums subtyping proposal later this year?

+1. Subtype relationship is mostly what is desired here.

Some people have also talked about members of the supertype also being available on the subtype which would involve implementation inheritance. That could probably be made to work for enums if the subtype receives identical storage and as long as all supertype members are considered final (because value type members are always final). But it's a slippery slope and would likely bloat the storage of many subtype enums.

-Matthew

> **···**
>
> Sent from my iPad
> 
> > On Jun 4, 2016, at 12:34 AM, Austin Zheng via swift-evolution \<swift-evolution@swift.org\> wrote:
> 
> > Austin
> > 
> > > > On Jun 3, 2016, at 10:25 PM, Chris Lattner \<clattner@apple.com\> wrote:
> > > > 
> > > > On Jun 3, 2016, at 2:35 PM, T.J. Usiyan via swift-evolution \<swift-evolution@swift.org\> wrote:
> > > > 
> > > > Since this seems to have some interest, I've made a gist.
> > > > 
> > > > [Enum Subsets · GitHub](https://gist.github.com/griotspeak/963bc87a0c244c120264b11fb022d78c)
> > > 
> > > We have frequently discussed introducing subtype relationships between structs and enums, in an effort to allow limited implicit promotions (e.g. from small integers to wider integers). Wouldn’t that be a more general solution to this same problem?
> > > 
> > > -Chris
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Chris\_Lattner](https://avatars.discourse-cdn.com/v4/letter/c/bc8723/32.png) [@Chris\_Lattner](https://forums.swift.org/u/Chris_Lattner)\
**Post date:** [June 4, 2016, 6:59pm UTC](https://forums.swift.org/t/proposal-enum-subsets/2869/16 "2016-06-04T18:59:30Z")

</div>

I would \*love\* to get it in Swift 3.x or Swift 4, but we’ll have to see. Generics features needed by the standard library will be higher priority, for example.

-Chris

> **···**
>
> > On Jun 3, 2016, at 10:34 PM, Austin Zheng \<austinzheng@gmail.com\> wrote:
> > 
> > It seems like it would make sense to model enum subsets as a subtype relationship.
> > 
> > Is the core team planning on drawing up a structs/enums subtyping proposal later this year?

---

<div class="post-metadata">

**Author:** ![griotspeak](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/griotspeak/32/1966_2.png) [@griotspeak](https://forums.swift.org/u/griotspeak)\
**Post date:** [June 6, 2016, 3:24am UTC](https://forums.swift.org/t/proposal-enum-subsets/2869/17 "2016-06-06T03:24:34Z")

</div>

Sub typing is the answer that we're going with then?

> **···**
>
> On Sat, Jun 4, 2016 at 4:26 PM, T.J. Usiyan \<griotspeak@gmail.com\> wrote:
> 
> > It could be a more general solution. I am unclear about what 'subtype  
> > relationships' means here though.
> > 
> > Are you talking a about what you allude to here?  
> > [[swift-evolution] Proposal: Auto-convert for numbers when safe](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151130/000525.html)
> > 
> > The benefit of explicitly narrowing, in my opinion, is that there is no  
> > unnecessary cost to figuring out lookup. (Please correct me if I am  
> > mistaken.) Implicit promotions introduce uncertainty with regard to what a  
> > value is being treated as in any given moment. This uncertainty is worth it  
> > in many cases but I will suggest that it is not worth it when trying to  
> > deal with a narrower set of cases from an already established set. For  
> > example, in the graph/lattice situation, conversions must be written  
> > because there is no reasonable conversion that can be assumed. In this  
> > proposal, the conversion is obvious and trivial because the relationship is  
> > completely clear.
> > 
> > All of that said, I \*am\* unclear about what subtype relationships means so  
> > it may very well be a better solution. It certainly sounds like a more  
> > general solution but I am not convinced that that is an advantage when  
> > trying to deal with a strict subset.
> > 
> > TJ  
> > On Sat, Jun 4, 2016 at 1:25 AM, Chris Lattner \<clattner@apple.com\> wrote:
> > 
> > > On Jun 3, 2016, at 2:35 PM, T.J. Usiyan via swift-evolution \< \>\> swift-evolution@swift.org\> wrote:
> > > 
> > > Since this seems to have some interest, I've made a gist.
> > > 
> > > [Enum Subsets · GitHub](https://gist.github.com/griotspeak/963bc87a0c244c120264b11fb022d78c)
> > > 
> > > We have frequently discussed introducing subtype relationships between  
> > > structs and enums, in an effort to allow limited implicit promotions (e.g.  
> > > from small integers to wider integers). Wouldn’t that be a more general  
> > > solution to this same problem?
> > > 
> > > -Chris

---

<div class="post-metadata">

**Author:** ![Chris\_Lattner](https://avatars.discourse-cdn.com/v4/letter/c/bc8723/32.png) [@Chris\_Lattner](https://forums.swift.org/u/Chris_Lattner)\
**Post date:** [June 8, 2016, 3:49am UTC](https://forums.swift.org/t/proposal-enum-subsets/2869/18 "2016-06-08T03:49:03Z")

</div>

> Sub typing is the answer that we're going with then?

Most likely. At this point, we’re not really accepting additive changes to Swift 3 anyway, so any proposal would need to wait until post-swift 3 in any case.

Plans for releases beyond Swift 3 haven’t been made yet - the metaplan is to come up with a plan in ~August timeframe.

-Chris

> **···**
>
> On Jun 5, 2016, at 8:24 PM, T.J. Usiyan via swift-evolution \<swift-evolution@swift.org\> wrote:
> 
> > On Sat, Jun 4, 2016 at 4:26 PM, T.J. Usiyan \<griotspeak@gmail.com \<mailto:griotspeak@gmail.com\>\> wrote:  
> > It could be a more general solution. I am unclear about what 'subtype relationships' means here though.
> > 
> > Are you talking a about what you allude to here? [[swift-evolution] Proposal: Auto-convert for numbers when safe](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151130/000525.html)
> > 
> > The benefit of explicitly narrowing, in my opinion, is that there is no unnecessary cost to figuring out lookup. (Please correct me if I am mistaken.) Implicit promotions introduce uncertainty with regard to what a value is being treated as in any given moment. This uncertainty is worth it in many cases but I will suggest that it is not worth it when trying to deal with a narrower set of cases from an already established set. For example, in the graph/lattice situation, conversions must be written because there is no reasonable conversion that can be assumed. In this proposal, the conversion is obvious and trivial because the relationship is completely clear.
> > 
> > All of that said, I \*am\* unclear about what subtype relationships means so it may very well be a better solution. It certainly sounds like a more general solution but I am not convinced that that is an advantage when trying to deal with a strict subset.
> > 
> > TJ  
> > On Sat, Jun 4, 2016 at 1:25 AM, Chris Lattner \<clattner@apple.com \<mailto:clattner@apple.com\>\> wrote:
> > 
> > > On Jun 3, 2016, at 2:35 PM, T.J. Usiyan via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > > 
> > > Since this seems to have some interest, I've made a gist.
> > > 
> > > [Enum Subsets · GitHub](https://gist.github.com/griotspeak/963bc87a0c244c120264b11fb022d78c)
> > 
> > We have frequently discussed introducing subtype relationships between structs and enums, in an effort to allow limited implicit promotions (e.g. from small integers to wider integers). Wouldn’t that be a more general solution to this same problem?
> > 
> > -Chris
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![mackoj](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mackoj/32/42395_2.png) [@mackoj](https://forums.swift.org/u/mackoj)\
**Post date:** [January 22, 2018, 10:42am UTC](https://forums.swift.org/t/proposal-enum-subsets/2869/19 "2018-01-22T10:42:49Z")

</div>

I would love to see the idea of subset resurface.

---

<div class="post-metadata">

**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\
**Post date:** [January 23, 2018, 8:49pm UTC](https://forums.swift.org/t/proposal-enum-subsets/2869/20 "2018-01-23T20:49:15Z")

</div>

same

[Next page](https://forums.swift.org/t/proposal-enum-subsets/2869.md?page=2)