[swift-evolution] [Proposal] Enum subsets
T.J. Usiyan
griotspeak at gmail.com
Fri Jun 3 08:22:23 CDT 2016
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)
## 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160603/2ae5d9f5/attachment.html>
More information about the swift-evolution
mailing list