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

Tue Dec 19 23:42:04 CST 2017

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.

-- Howard.

> 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/20171219/3a42fa54/attachment.html>