[Proposal] Allow enumerating cases in enumerations

Hello, this has been proposed multiple times before in different ways.

Link to detailed proposal draft:
https://github.com/gabriellanata/swift-evolution/blob/master/proposals/NNNN-allow-enumerating-cases-in-enumerations.md

It is currently not possible to enumerate through all the possible cases of
an enumeration object without adding a hardcoded value or recurring to
unsafe workarounds. The proposal is to add a method of obtaining an array
or set of all the possible cases natively for enumerations without
associated values.

The proposed solution is to implement a native `.cases` static var for all
enumerations without associated values. This would provide a strict
type-safe way of enumerating though the possible cases without risking
runtime errors. The resulting code is a lot cleaner and less prone to
errors caused by forgetting to update the hardcoded values when modifying
cases.

Resulting code:

   enum PokemonType {
       case Fire, Grass, Water, Wind
   }
   for pokemonType in PokemonType.cases {
       // Do stuff
   }
   PokemonType.cases.count // Returns 4

···

-------
Gabriel

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&gt;

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.

···

On Jul 3, 2016, at 6:36 PM, Gabriel Lanata via swift-evolution <swift-evolution@swift.org> wrote:

--
Brent Royal-Gordon
Architechies

+1 since it makes it easy to get the number of possible enum values, but I
thought I'd tell you: there's no "Wind" type in Pokémon. It's "Flying".

···

On Sun, Jul 3, 2016 at 18:36 Gabriel Lanata via swift-evolution < swift-evolution@swift.org> wrote:

Hello, this has been proposed multiple times before in different ways.

Link to detailed proposal draft:

https://github.com/gabriellanata/swift-evolution/blob/master/proposals/NNNN-allow-enumerating-cases-in-enumerations.md

It is currently not possible to enumerate through all the possible cases
of an enumeration object without adding a hardcoded value or recurring to
unsafe workarounds. The proposal is to add a method of obtaining an array
or set of all the possible cases natively for enumerations without
associated values.

The proposed solution is to implement a native `.cases` static var for
all enumerations without associated values. This would provide a strict
type-safe way of enumerating though the possible cases without risking
runtime errors. The resulting code is a lot cleaner and less prone to
errors caused by forgetting to update the hardcoded values when modifying
cases.

Resulting code:

   enum PokemonType {
       case Fire, Grass, Water, Wind
   }
   for pokemonType in PokemonType.cases {
       // Do stuff
   }
   PokemonType.cases.count // Returns 4

-------
Gabriel

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Saagar Jha

Hi there,

right now, I have 7115 unread messages in my Swift-folder, so I'm surprised that there hasn't already been a successful proposal to add this feature… afaiks, it wouldn't hurt anybody, and many people want to have it.

Therefore:
+1, and good luck! ;-)

+1

Finally, let’s get it done

···

On 4 Jul 2016, at 03:36, Gabriel Lanata via swift-evolution <swift-evolution@swift.org> wrote:

Hello, this has been proposed multiple times before in different ways.

Link to detailed proposal draft:
https://github.com/gabriellanata/swift-evolution/blob/master/proposals/NNNN-allow-enumerating-cases-in-enumerations.md

It is currently not possible to enumerate through all the possible cases of an enumeration object without adding a hardcoded value or recurring to unsafe workarounds. The proposal is to add a method of obtaining an array or set of all the possible cases natively for enumerations without associated values.

The proposed solution is to implement a native `.cases` static var for all enumerations without associated values. This would provide a strict type-safe way of enumerating though the possible cases without risking runtime errors. The resulting code is a lot cleaner and less prone to errors caused by forgetting to update the hardcoded values when modifying cases.

Resulting code:

   enum PokemonType {
       case Fire, Grass, Water, Wind
   }
   for pokemonType in PokemonType.cases {
       // Do stuff
   }
   PokemonType.cases.count // Returns 4

-------
Gabriel

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Those who haven't followed earlier discussions may be interested in reading
the most recent thread, from April:
http://thread.gmane.org/gmane.comp.lang.swift.evolution/14674

···

On Mon, Jul 4, 2016 at 12:14 AM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote:

> On Jul 3, 2016, at 6:36 PM, Gabriel Lanata via swift-evolution < > swift-evolution@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&gt;

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@swift.org> wrote:

On Jul 3, 2016, at 6:36 PM, Gabriel Lanata via swift-evolution <swift-evolution@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&gt;

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Now that you mention it; why is Bool not an enum?

Karl

···

On 4 Jul 2016, at 09:14, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

On Jul 3, 2016, at 6:36 PM, Gabriel Lanata via swift-evolution <swift-evolution@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&gt;

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.

Would love a real life scenario of why you would need this.

···

*___________________________________*

*James⎥Head of Trolls*

*james@supmenow.com <james@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 4 July 2016 at 02:36, Gabriel Lanata via swift-evolution < swift-evolution@swift.org> wrote:

Hello, this has been proposed multiple times before in different ways.

Link to detailed proposal draft:

https://github.com/gabriellanata/swift-evolution/blob/master/proposals/NNNN-allow-enumerating-cases-in-enumerations.md

It is currently not possible to enumerate through all the possible cases
of an enumeration object without adding a hardcoded value or recurring to
unsafe workarounds. The proposal is to add a method of obtaining an array
or set of all the possible cases natively for enumerations without
associated values.

The proposed solution is to implement a native `.cases` static var for
all enumerations without associated values. This would provide a strict
type-safe way of enumerating though the possible cases without risking
runtime errors. The resulting code is a lot cleaner and less prone to
errors caused by forgetting to update the hardcoded values when modifying
cases.

Resulting code:

   enum PokemonType {
       case Fire, Grass, Water, Wind
   }
   for pokemonType in PokemonType.cases {
       // Do stuff
   }
   PokemonType.cases.count // Returns 4

-------
Gabriel

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I know! I am amazed this hasn’t had a formal proposal and review yet. I did a search through the mailing list and found that it has been mentioned many times before (these mentions are linked in the proposal) but it has never gone into review. The other posts proposed slightly different solutions which were not as intuitive, the solution I’m proposing is the simplest and most useful way it can be implemented.

···

-------
Gabriel

On Jul 4, 2016, 12:47 AM -0500, Tino Heth<2th@gmx.de>, wrote:

Hi there,

right now, I have 7115 unread messages in my Swift-folder, so I'm surprised that there hasn't already been a successful proposal to add this feature… afaiks, it wouldn't hurt anybody, and many people want to have it.

Therefore:
+1, and good luck! ;-)

+1. The only thing that I don't like is that it may lead to confusion to
novice developers because it only work with "basic" enums i.e. enums
without associated values. The same thing happens with protocols with
associated types, where you can't use the protocol with associated types as
the type of properties, variables or constants like "basic" protocols.

···

El dom., 3 jul. 2016 a las 21:58, Saagar Jha via swift-evolution (< swift-evolution@swift.org>) escribió:

+1 since it makes it easy to get the number of possible enum values, but I
thought I'd tell you: there's no "Wind" type in Pokémon. It's "Flying".
On Sun, Jul 3, 2016 at 18:36 Gabriel Lanata via swift-evolution < > swift-evolution@swift.org> wrote:

Hello, this has been proposed multiple times before in different ways.

Link to detailed proposal draft:

https://github.com/gabriellanata/swift-evolution/blob/master/proposals/NNNN-allow-enumerating-cases-in-enumerations.md

It is currently not possible to enumerate through all the possible cases
of an enumeration object without adding a hardcoded value or recurring to
unsafe workarounds. The proposal is to add a method of obtaining an array
or set of all the possible cases natively for enumerations without
associated values.

The proposed solution is to implement a native `.cases` static var for
all enumerations without associated values. This would provide a strict
type-safe way of enumerating though the possible cases without risking
runtime errors. The resulting code is a lot cleaner and less prone to
errors caused by forgetting to update the hardcoded values when
modifying cases.

Resulting code:

   enum PokemonType {
       case Fire, Grass, Water, Wind
   }
   for pokemonType in PokemonType.cases {
       // Do stuff
   }
   PokemonType.cases.count // Returns 4

-------
Gabriel

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Saagar Jha
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

That's why we have retroactive modeling. :^)

  import SomeEnumKit
  extension SomeEnum: ValuesEnumerable {}

You can extend another module's public enum to add conformance to a protocol, and there's no reason it can't generate the code in your module instead of theirs.

···

On Jul 4, 2016, at 10:43 AM, Leonardo Pessoa <me@lmpessoa.com> wrote:

My issue with this being opt-in is third-party libraries.

--
Brent Royal-Gordon
Architechies

That is actually something I argued over this list with other users
and (at least when I proposed) was not very well accepted. This
certainly has my +1.

···

On 4 July 2016 at 02:52, Gabriel Lanata via swift-evolution <swift-evolution@swift.org> wrote:

I know! I am amazed this hasn’t had a formal proposal and review yet. I did
a search through the mailing list and found that it has been mentioned many
times before (these mentions are linked in the proposal) but it has never
gone into review. The other posts proposed slightly different solutions
which were not as intuitive, the solution I’m proposing is the simplest and
most useful way it can be implemented.

-------
Gabriel

On Jul 4, 2016, 12:47 AM -0500, Tino Heth <2th@gmx.de>, wrote:

Hi there,

right now, I have 7115 unread messages in my Swift-folder, so I'm surprised
that there hasn't already been a successful proposal to add this feature…
afaiks, it wouldn't hurt anybody, and many people want to have it.

Therefore:
+1, and good luck! ;-)

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Probably, for the same reason Int is not an enum.

···

2016-07-04 18:34 GMT+03:00 Karl via swift-evolution < swift-evolution@swift.org>:

Now that you mention it; why is Bool *not* an enum?

Yes, but I can't understand, why not give this ability to each enum? It seems like this feature is a very basic thing that enum must(IMO) to have.
What kind of overhead this will generate? Static function or property that returns array as I understand should not generate any impact on memory required to store each separate *instance* of enum. I don't believe that adding a number of bytes to enum *type* to implement .allValues(or whatever named) will have any difference for total application/framework.

···

On 04.07.2016 21:21, Brent Royal-Gordon via swift-evolution wrote:

On Jul 4, 2016, at 10:43 AM, Leonardo Pessoa <me@lmpessoa.com> wrote:

My issue with this being opt-in is third-party libraries.

That's why we have retroactive modeling. :^)

  import SomeEnumKit
  extension SomeEnum: ValuesEnumerable {}

You can extend another module's public enum to add conformance to a protocol, and there's no reason it can't generate the code in your module instead of theirs.

Example:

enum MediaKind {
  case HomeVideo, Movie, MusicVideo, TVShow

  var localizedName: String { ... }
}

let popUpButton: NSPopUpButton = ...
for kind in MediaKind.allKinds {
  popUpButton.addItemWithTitle(kind.localizedName)
}

And many, many more.

···

On Jul 5, 2016, at 12:33 PM, James Campbell via swift-evolution <swift-evolution@swift.org> wrote:

Would love a real life scenario of why you would need this.

___________________________________

James⎥Head of Trolls

james@supmenow.com <mailto:james@supmenow.com>⎥supmenow.com <http://supmenow.com/&gt;
Sup

Runway East >

10 Finsbury Square

London

> EC2A 1AF

On 4 July 2016 at 02:36, Gabriel Lanata via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hello, this has been proposed multiple times before in different ways.

Link to detailed proposal draft:
https://github.com/gabriellanata/swift-evolution/blob/master/proposals/NNNN-allow-enumerating-cases-in-enumerations.md

It is currently not possible to enumerate through all the possible cases of an enumeration object without adding a hardcoded value or recurring to unsafe workarounds. The proposal is to add a method of obtaining an array or set of all the possible cases natively for enumerations without associated values.

The proposed solution is to implement a native `.cases` static var for all enumerations without associated values. This would provide a strict type-safe way of enumerating though the possible cases without risking runtime errors. The resulting code is a lot cleaner and less prone to errors caused by forgetting to update the hardcoded values when modifying cases.

Resulting code:

   enum PokemonType {
       case Fire, Grass, Water, Wind
   }
   for pokemonType in PokemonType.cases {
       // Do stuff
   }
   PokemonType.cases.count // Returns 4

-------
Gabriel

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Would love a real life scenario of why you would need this.

Some kind of pre-initialization(for GUI as example) for all possible kinds of values, that you should process then (for GUI - let's say add to needed list).

···

On 05.07.2016 13:33, James Campbell via swift-evolution wrote:

*___________________________________*

*James⎥Head of Trolls*

*james@supmenow.com <mailto:james@supmenow.com>⎥supmenow.com
<http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 4 July 2016 at 02:36, Gabriel Lanata via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

    Hello, this has been proposed multiple times before in different ways.

    Link to detailed proposal draft:
    https://github.com/gabriellanata/swift-evolution/blob/master/proposals/NNNN-allow-enumerating-cases-in-enumerations.md

    It is currently not possible to enumerate through all the possible
    cases of an enumeration object without adding a hardcoded value or
    recurring to unsafe workarounds. The proposal is to add a method of
    obtaining an array or set of all the possible cases natively for
    enumerations without associated values.

    The proposed solution is to implement a native `.cases` static var for
    all enumerations without associated values. This would provide a strict
    type-safe way of enumerating though the possible cases without risking
    runtime errors. The resulting code is a lot cleaner and less prone to
    errors caused by forgetting to update the hardcoded values when
    modifying cases.

    Resulting code:

       enum PokemonType {
           case Fire, Grass, Water, Wind
       }
       for pokemonType in PokemonType.cases {
           // Do stuff
       }
       PokemonType.cases.count // Returns 4

    -------
    Gabriel

    _______________________________________________
    swift-evolution mailing list
    swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

And it is something the compiler can check whether it is necessary for
your code or not based on some simple and easy pattern. If it is so
simple, why not let the compiler handle it?

···

On 4 July 2016 at 16:02, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

On 04.07.2016 21:21, Brent Royal-Gordon via swift-evolution wrote:

On Jul 4, 2016, at 10:43 AM, Leonardo Pessoa <me@lmpessoa.com> wrote:

My issue with this being opt-in is third-party libraries.

That's why we have retroactive modeling. :^)

        import SomeEnumKit
        extension SomeEnum: ValuesEnumerable {}

You can extend another module's public enum to add conformance to a
protocol, and there's no reason it can't generate the code in your module
instead of theirs.

Yes, but I can't understand, why not give this ability to each enum? It
seems like this feature is a very basic thing that enum must(IMO) to have.
What kind of overhead this will generate? Static function or property that
returns array as I understand should not generate any impact on memory
required to store each separate *instance* of enum. I don't believe that
adding a number of bytes to enum *type* to implement .allValues(or whatever
named) will have any difference for total application/framework.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Maybe a way we could opt in is by only doing this for enums with out
turples?

i.e

enum ABTestingBrah {

case A
case B

}

I'm not sure if enums that take turples would need this functionality.

···

*___________________________________*

*James⎥Head of Trolls*

*james@supmenow.com <james@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 5 July 2016 at 11:39, Charlie Monroe <charlie@charliemonroe.net> wrote:

Example:

enum MediaKind {
case HomeVideo, Movie, MusicVideo, TVShow

var localizedName: String { ... }
}

let popUpButton: NSPopUpButton = ...
for kind in MediaKind.allKinds {
popUpButton.addItemWithTitle(kind.localizedName)
}

And many, many more.

On Jul 5, 2016, at 12:33 PM, James Campbell via swift-evolution < > swift-evolution@swift.org> wrote:

Would love a real life scenario of why you would need this.

*___________________________________*

*James⎥Head of Trolls*

*james@supmenow.com <james@supmenow.com>⎥supmenow.com
<http://supmenow.com/&gt;\*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 4 July 2016 at 02:36, Gabriel Lanata via swift-evolution < > swift-evolution@swift.org> wrote:

Hello, this has been proposed multiple times before in different ways.

Link to detailed proposal draft:

https://github.com/gabriellanata/swift-evolution/blob/master/proposals/NNNN-allow-enumerating-cases-in-enumerations.md

It is currently not possible to enumerate through all the possible cases
of an enumeration object without adding a hardcoded value or recurring to
unsafe workarounds. The proposal is to add a method of obtaining an array
or set of all the possible cases natively for enumerations without
associated values.

The proposed solution is to implement a native `.cases` static var for
all enumerations without associated values. This would provide a strict
type-safe way of enumerating though the possible cases without risking
runtime errors. The resulting code is a lot cleaner and less prone to
errors caused by forgetting to update the hardcoded values when
modifying cases.

Resulting code:

   enum PokemonType {
       case Fire, Grass, Water, Wind
   }
   for pokemonType in PokemonType.cases {
       // Do stuff
   }
   PokemonType.cases.count // Returns 4

-------
Gabriel

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

This is mentioned in Gabriel's proposal:

Implement a native .cases static var for all enumerations without associated values

But as has been mentioned in the discussion, this was mentioned by Brent:

···

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.

On Jul 5, 2016, at 12:43 PM, James Campbell <james@supmenow.com> wrote:

Maybe a way we could opt in is by only doing this for enums with out turples?

i.e

enum ABTestingBrah {

case A
case B

}

I'm not sure if enums that take turples would need this functionality.

___________________________________

James⎥Head of Trolls

james@supmenow.com <mailto:james@supmenow.com>⎥supmenow.com <http://supmenow.com/&gt;
Sup

Runway East >

10 Finsbury Square

London

> EC2A 1AF

On 5 July 2016 at 11:39, Charlie Monroe <charlie@charliemonroe.net <mailto:charlie@charliemonroe.net>> wrote:
Example:

enum MediaKind {
  case HomeVideo, Movie, MusicVideo, TVShow

  var localizedName: String { ... }
}

let popUpButton: NSPopUpButton = ...
for kind in MediaKind.allKinds {
  popUpButton.addItemWithTitle(kind.localizedName)
}

And many, many more.

On Jul 5, 2016, at 12:33 PM, James Campbell via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Would love a real life scenario of why you would need this.

___________________________________

James⎥Head of Trolls

james@supmenow.com <mailto:james@supmenow.com>⎥supmenow.com <http://supmenow.com/&gt;
Sup

Runway East >>

10 Finsbury Square

London

>> EC2A 1AF

On 4 July 2016 at 02:36, Gabriel Lanata via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hello, this has been proposed multiple times before in different ways.

Link to detailed proposal draft:
https://github.com/gabriellanata/swift-evolution/blob/master/proposals/NNNN-allow-enumerating-cases-in-enumerations.md

It is currently not possible to enumerate through all the possible cases of an enumeration object without adding a hardcoded value or recurring to unsafe workarounds. The proposal is to add a method of obtaining an array or set of all the possible cases natively for enumerations without associated values.

The proposed solution is to implement a native `.cases` static var for all enumerations without associated values. This would provide a strict type-safe way of enumerating though the possible cases without risking runtime errors. The resulting code is a lot cleaner and less prone to errors caused by forgetting to update the hardcoded values when modifying cases.

Resulting code:

   enum PokemonType {
       case Fire, Grass, Water, Wind
   }
   for pokemonType in PokemonType.cases {
       // Do stuff
   }
   PokemonType.cases.count // Returns 4

-------
Gabriel

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution