On Mon, Jan 8, 2018 at 11:02 AM Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:
> Hello Swift community, > > The review of SE-0194 "Derived Collection of Enum Cases" begins now and > runs through January 11, 2018. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md > > Reviews are an important part of the Swift evolution process. All reviews > should be sent to the swift-evolution mailing list at > > https://lists.swift.org/mailman/listinfo/swift-evolution > > or, if you would like to keep your feedback private, directly to the > review manager. When replying, please try to keep the proposal link at the > top of the message: > > Proposal link: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md > > Reply text > > Other replies > > > <https://github.com/apple/swift-evolution/pull/114#what-goes-into-a-review-1>What > goes into a review? > > The goal of the review process is to improve the proposal under review > through constructive criticism and, eventually, determine the direction of > Swift. When writing your review, here are some questions you might want to > answer in your review: > > - What is your evaluation of the proposal? > > Big +1. I've been looking forward to something like this for a long time. I'm extremely happy with the API chosen here. ValueEnumerable and allValues are absolutely the correct names, because the protocol is not *restricted* to enums, it is merely *synthesized automatically* for enums. That's a very important distinction. Someone could provide their own conformance to ValueEnumerable and use it in generic algorithms and have everything work as expected. In a perfect world I would argue that the associated type of allValues should be a Sequence instead of a Collection as this would allow it to be extended to infinite sequences (i.e., cases with associated values that are deeply ValueEnumerable), but I'll admit that I've never come up with a compelling use case for this beyond obscure combinatorial algorithms. Since getting the count of values is important to many users, Collection is a reasonable compromise and I don't have any objections. > > - Is the problem being addressed significant enough to warrant a > change to Swift? > > Yes. It's a frequently requested feature and has utility both in UI-driven logic (table view sections based on an enum) and other algorithms. > > - Does this proposal fit well with the feel and direction of Swift? > > Yes. The API design fits right into other stdlib concepts, and the conditions for synthesis align with the synthesis of other synthesized protocols. > > - If you have used other languages or libraries with a similar > feature, how do you feel that this proposal compares to those? > > Just Java's values() function that is present on all enums. The functionality provided here is what I would expect, similar to other languages. > > - How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? > > An in-depth read and I was heavily involved in some of the earlier discussion threads. > More information about the Swift evolution process is available at > > https://github.com/apple/swift-evolution/blob/master/process.md > > Thank you, > > -Doug Gregor > > Review Manager > _______________________________________________ > 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
