[swift-evolution] [Proposal] Enum subsets

[Austin Zheng]

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 at 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)
>
> ## 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160603/d9ef7c51/attachment.html>