Zef, do you really think `rawValues` are worth adding? With `cases`, they would be one `map` away, no?
R+ > On 23 Dec 2015, at 17:21, Zef Houssney via swift-evolution > <swift-evolution@swift.org> wrote: > > To be clear, I think there should be a distinction between what would be > returned by `cases` and `rawValues`, and I think there is good reason to > include both: > > - `cases` would return actual instances of the enum type, or the constructor > if there is an associated value for the case and an instance can’t be > automatically created > - `rawValues` would also exist for enums that have a RawRepresentable value. > > The collision of using “case" in something like `for case in SomeEnum.cases` > is unfortunate, but I think it’s still the most clear and accurate > representation of something that does what I described above. Initially I was > thinking there was an existing proposal that would fix this, but now I > realize that it’s only scoped to keyword arguments: > https://github.com/apple/swift-evolution/blob/master/proposals/0001-keywords-as-argument-labels.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0001-keywords-as-argument-labels.md> > > > Joe, thank you for your thoughts on this! Yes I agree that it doesn’t make > sense to try to generate a list of all possible values for all associated > types — and that’s pretty much my point. Deciding to omit such unsupported > cases is one way to deal with that issue, but it seems confusing and limiting > to me that some enum cases would not be represented in the array of values, > while others are represented multiple times. I’m not saying that there’s no > value to something like that and I’m certainly not opposed to the inclusion > of that kind of thing, but I’m interested in finding a way to deal with this > in a manner that is more understandable, predictable, and flexible. > > I’d love to hear what you think about returning an array that includes > constructors for the cases with associated values. Here’s what I like about > that idea: > > - The array consists of a 1-to-1 mapping regardless of the type of case. This > is more understandable and predictable in my opinion. > - It provides the ability to cover more use-cases, while I believe the other > approach would prevent certain things from being possible in a dynamic way. > - It still allows for developers to generate an array with the recursive > structure/Cartesian product as you described. > > Here is an example that demonstrates the usefulness of constructors as the > included value for cases with associated values. I am providing a stubbed > implementation of a `cases` static var. The concept is that you have an enum > that defines a number of built-in color schemes, but provides a mechanism for > users to dynamically create their own color schemes. > > https://gist.github.com/zef/c6069ed4ed11e41661bf > <https://gist.github.com/zef/c6069ed4ed11e41661bf> > > I have a couple other real-world ideas for where this would be useful too. > > > Downsides I can see to this approach: > > - For enums that have disparate constructor signatures, [Any] would have to > be the return value of cases, which doesn’t seem ideal because the cases > array would always require some kind of manual manipulation to be useful. > - There isn’t currently a way in the type system to know what case you are > working based on the constructor. For instance say two cases both have a > constructor of (String), you can’t determine which case you are working on > until you call the constructor to instantiate the case. This could be done by > looking at the index of the constructor in the cases array, but that is > brittle and messy. If there was a way to determine that more dynamically, > this would be more powerful and easier to use. > > > > >> On Dec 23, 2015, at 6:00 AM, Pierre Monod-Broca via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> +1 for an ordered collection of all cases, it could be an ordered set to >> please proponents of a set. >> >> I have no strong opinions about the name >> `cases` is good, but I agree it begs to do ''for case in SomeEnum.cases'' >> `values` is good, and IMO it's consistent with `rawValue` when there is one, >> not confusing >> >> -- >> Pierre >> >> >> _______________________________________________ >> 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
