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

Wed Dec 20 00:34:13 CST 2017

On Wed, Dec 20, 2017 at 12:42 AM, Howard Lovatt <howard.lovatt at gmail.com>
wrote:

> Let me give an example. The recent discussion about filterMap aired in the
> discussion stage misgivings about the name; but it went to review with the
> name filterMap. At the review stage more misgivings were raised, the review
> was returned for amendment. An amended name of compactMap was put forward
> and this was accepted yesterday as a result of the 2nd review. I think that
> this shows how the process can work well. If the discussions were shut down
> with “already covered on Swift Evolution”, then the result wouldn’t be as
> good.
>
> If an argument has been put forward on Evolution, is in the alternatives
> section, and people are still raising the point; it is probably safe to
> assume that the argument hasn’t carried the day and should be revisited.
>

The name of `filterMap` was reviewed a second time because, if I recall,
the core team felt that there might be _additional_ ideas not yet surveyed
the first time. By contrast, if an argument has already been discussed and
is even incorporated into the text of the proposal, then I very strongly
disagree that raising the point again is to be encouraged. It's a different
matter if you have additional _evidence_ or alternative _reasoning_ to
support an argument.

On 19 Dec 2017, at 6:44 pm, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> 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/20171220/ad7544c4/attachment.html>