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
> <[email protected]> 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>)
>
> ## 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
