[swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

Wed Jan 10 00:26:01 CST 2018

On Mon, Jan 8, 2018 at 1:02 PM, Douglas Gregor via swift-evolution <
swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180110/e2e4fbcc/attachment.html>