On Mon, Jan 8, 2018 at 1:02 PM, 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? > > I continue to have concerns about this proposal, and I'm gravely and very bitterly disappointed that the concerns have not even been acknowledged in the Alternatives section, which is in my view the minimum action that an author should take when points are raised during a pitch phase, even (and especially) when the author disagrees, along with a cogent write-up of why the proposed design is superior in the author's view to the alternative. In this case, the proposal authors write: "The community has not raised any solutions whose APIs differ significantly from this proposal, except for solutions which provide strictly more functionality." This is false, as I have offered a solution in the past whose API differs entirely from this proposal, and which provides strictly a subset of the functionality which goes to the core of the issue at stake. In the past, I have stated on this list that once a statement has been made, it should not be repeated simply because one is disappointed in the outcome, as one should operate on the presumption that all actors proceed in good faith and have already considered the statement. Here, however, given that the write-up literally denies the existence of what I have already written, I will restate my concerns here once again. I would expect that on revision the authors will properly record a considered reply. My objection to the "ValueEnumerable" design--especially in its generalized form here (versus "CaseEnumerable")--is that the protocol's semantics (and, we'll recall, protocols in Swift must offer semantics that make possible useful generic algorithms) are so broad as to be little more than essentially what it means to be a type. Earlier in this thread (or was it in the companion one?), another community member suggested that if `allValues` were to conform to `Sequence` instead of `Collection`, then even types that have an infinite number of possible values could conform to `ValueEnumerable`. Here's the rub: the definition of a type, or at least one of them, _is_ precisely the set of all possible values of a variable. If unconstrained by finiteness, then *all types* would meet the semantic requirements of `ValueEnumerable`. As proposed, "`ValueEnumerable`...indicate[s] that a type has a finite, enumerable set of values"; now, we have the constraint that the type merely must have an upper bound in terms of memory referenced. Brent just wrote that he might later propose to extend `ValueEnumerable` to `Bool` and `Optional`, but theoretically and practically speaking it appears that it can correctly be extended to any type in the standard library that is not a `Sequence`, and with minimal effort even `Collection` types of fixed size (e.g., CollectionOfOne<T> with the right constraints as to the generic type T). Put another way, there are two issues with generalizing the very specific use case of "I want to know all the cases of an enum" to what is proposed here in terms of a protocol. First, "ValueEnumerable"-ness is neither universal to all enums (as those with associated types, indirect cases (think of all those tutorials about linked lists implemented as Swift enums), etc., are clearly not enumerable) nor unique as a property of enums, yet this proposal first makes a large generalization of the proposed protocol's semantics when the stated motivation is only about enums, then proceeds only to implement protocol conformance for enums. Second, the collection of all values is properly just the type and not a property of the type, for the reasons outlined above. So far, the justification I have heard for ignoring this objection is that (a) lots of people want the specific use case of knowing all the cases of an enum; and (b) a complete design which makes metatypes conform to `Collection` is not feasible for Swift 5. But that, in my view, cannot justify the _permanent_ inclusion (with ABI stability) of a protocol whose semantics apply to all non-`Sequence` types, littering the standard library and untold many other libraries with this conformance for the sake of having something done for Swift 5. My suggestion was, and is: if the motivation is to enumerate all the cases of an enum, deliver the best possible design for the specifically motivated use case rather than trying to deliver the most easy-to-implement design for the most general use case. In other words, give properly conformed enums (e.g. `enum MyEnum : Enumerable`--and I do suggest shortening the name, since what's enumerable is "the set of all values" == "the type") the synthesized ability to have all cases enumerated by iterating over the metatype: `for case in MyEnum.self { ... }`. Add as much other `Collection` functionality as can be implemented in the Swift 5 timeframe, starting with the most pressing based on the motivating use case. Then deliver more and more of the best possible design with each version of Swift as engineering resources permit. > - Is the problem being addressed significant enough to warrant a > change to Swift? > > The specific use case of finding all cases of an enum is well motivated, and significant enough. I see no motivation in the text for the proposed generalized formulation of the proposed protocol's semantics and continue to have grave concerns. > > - Does this proposal fit well with the feel and direction of Swift? > > In my view, no. > > - If you have used other languages or libraries with a similar > feature, how do you feel that this proposal compares to those? > > The proposal compares this to reflection facilities in other languages. I have used reflection in other languages, and the proposed semantics here aren't entirely about that, nor does the proposed solution delineate how it fits into a vision of Swift's future reflection facilities. > > - How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? > > In-depth study. > 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