On Wed, Dec 20, 2017 at 12:42 AM, Howard Lovatt <howard.lov...@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...@gmail.com> wrote: > > On Tue, Dec 19, 2017 at 11:15 PM, Howard Lovatt via swift-evolution < > swift-evolution@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 <kreme...@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@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
