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). 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
