[swift-evolution] [Proposal] Allow enumerating cases in enumerations

[Leonardo Pessoa]

My issue with this being opt-in is third-party libraries. The
developer of a library may not have intended or thought of a use for
the enum this way but some other developer might have. Being opt-in
would prevent such scenarios from easily happening or require the
developer to (again) manually implement the feature. Also, it should
be possible to opmise the compiler so it dynamically generates or
suppresses the property as needed by an app as the compiler has to
know all the values possible (or it could not demand us to write
exaustive switches).

L

On 4 July 2016 at 04:14, Brent Royal-Gordon via swift-evolution
<swift-evolution at swift.org> wrote:
>> On Jul 3, 2016, at 6:36 PM, Gabriel Lanata via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> Hello, this has been proposed multiple times before in different ways.
>
> It has indeed. Unfortunately, for various reasons it did not get into review in time, and Swift 3 is basically closed to additive features at this point. Our last pull request to get it reviewed has now been tagged "out of scope for current release". <https://github.com/apple/swift-evolution/pull/114>
>
>> The proposed solution is to implement a native `.cases` static var for all enumerations without associated values.
>
>
> That was one of many things we discussed in previous threads. `cases` isn't good because the natural variable you'd want to use in a `for` loop is `case`:
>
>         for case in PokemonType.cases { … }
>
> And also because other types which aren't technically enums, such as `Bool`, may want to expose their "cases" through the same mechanism.
>
> From the proposal:
>
>> The resulting areay of cases are ordered in the way they appear in the source code.
>
>
> Here's one of the sticking points: Should this actually be an array, or should it be some other kind of collection? An array takes up space to store its elements, and for many enums there's no actual reason it needs to. Using a custom collection instead could save memory.
>
>> I believe this behaviour should be natively available to all enums. There is no reason to require that enums conform to the protocol if this behaviour could be used in all of them.
>
> In previous discussions, the core team specifically asked that this be opt-in so that types which don't want it don't need to "pay" for it.
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution