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
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.
···
On Jul 3, 2016, at 6:36 PM, Gabriel Lanata via swift-evolution <swift-evolution@swift.org> wrote:
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
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.
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
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>
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>
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 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>
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.
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
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.
+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.
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
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.
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.
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.
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 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.
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
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:
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
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.
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.
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
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.
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