[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