[swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

[Xiaodi Wu]

On Tue, Dec 19, 2017 at 11:15 PM, Howard Lovatt via swift-evolution <
swift-evolution at swift.org> wrote:

> As an aside: there seems to be increasingly comments about proposals that
> say:
>
>   1. This was discussed at the evaluation stage and rejected.
>   2. This is how it is implemented in the patch.
>
> And other comments along those lines. Neither the pre-proposal discussions
> nor the proposed implementation are intended to limit the scope of the
> review. Therefore I don’t think people should raise this as reasons. You
> should remember that the process is deliberately staged this way and
> different people may well be commenting (in fact the process rather assumes
> that people in the formal review will be a wider set of people).
>
>
No, previous discussion don't limit the scope of review per se, but it's
not helpful to rehash the same arguments again. We want to encourage
everyone to contribute their most thought-out comments as early in the
process as possible to give those who propose ideas the fullest chance to
flesh out any revisions. However, everyone has finite time to contribute,
and if the same discussions are merely replayed at every stage of review,
then the process actively discourages thoughtful early participation. After
all, why bother defending ideas at the pre-proposal stage if I'm going to
have to spend the time repeating myself in a few months' time anyway?

Of course, if a wider set of people have _new_ comments, those are welcome
at a later stage. But, there seems to be a sense that if _I_ haven't said
something already, then _I_ should say it whether or not the same viewpoint
has already been aired. In my view, such an approach should be actively
discouraged for the reasons above. Although a strong consensus within the
community should certainly be accounted for, this list--even at the formal
review stage--doesn't even come close to approximating the community of
Swift users at large. Thus, review is not a vote-counting exercise to
maximize the number of people who chime in, but rather it is meant to
maximize the number of ideas and perspectives that are aired. If it's
already been said, it doesn't need to be said again, even if _I_ haven't
said it myself.


> Anyway gripe over.
>
> Proposal link: https://github.com/apple/swift-evolution/blob/
> master/proposals/0192-non-exhaustive-enums.md
>
>
>    -
>
>    What is your evaluation of the proposal?
>
>    +1/2
>
>    I only give this a half because whilst it is important I can see three
>    issues:
>
>      1. It doesn’t seem very Swift like to have a different rule, default
>    non-exhaustive, for public as opposed to non-public.
>
>      2. It doesn’t seem very Swift like to have the default the unsafe
>    case.
>
>      3. Other languages have better solutions - see below under other
>    languages
>    -
>
>    Is the problem being addressed significant enough to warrant a change
>    to Swift?
>
>    Yes, Swift ABI compatibility going forwards is important
>    -
>
>    Does this proposal fit well with the feel and direction of Swift?
>
>    No. As mentioned above different rules for public and a non-safe
>    default don’t see that Swift like.
>    -
>
>    If you have used other languages or libraries with a similar feature,
>    how do you feel that this proposal compares to those?
>
>    Both Java and Scala have a better solution. In these languages enums
>    (Scala calls them case classes) can implement protocols and the user of an
>    enum rarely writes a switch statement, instead they call protocol methods.
>    Enums in these languages are a fixed set of derived classes; i.e. normal OO
>    programming rather than functional programming, which works well in the
>    case of wanting to expand later the number of enum cases.
>    -
>
>    How much effort did you put into your review? A glance, a quick
>    reading, or an in-depth study?
>    Have followed the discussions. Used enums in Swift and other languages
>    extensively.
>
>
> -- Howard.
>
> On 19 Dec 2017, at 12:58 pm, Ted Kremenek <kremenek at apple.com> wrote:
>
> 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/0192-non-exhaustive-enums.md
> ...
> Reply text
> ...
> Other replies
>
> What goes into a review of a proposal?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift.
>
> When reviewing a proposal, here are some questions to consider:
>
>    -
>
>    What is your evaluation of the proposal?
>    -
>
>    Is the problem being addressed significant enough to warrant a change
>    to Swift?
>    -
>
>    Does this proposal fit well with the feel and direction of Swift?
>    -
>
>    If you have used other languages or libraries with a similar feature,
>    how do you feel that this proposal compares to those?
>    -
>
>    How much effort did you put into your review? A glance, a quick
>    reading, or an in-depth study?
>
>
> _______________________________________________
> 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/20171219/80c26495/attachment.html>