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:
```
enum LCDColors : Colors {
case red, green, blue
}
```
or perhaps
```
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:
```
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:
```
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
> <[email protected]> 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 <[email protected]
> <mailto:[email protected]>> 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
>> <[email protected] <mailto:[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] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
>
> _______________________________________________
> 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
