<div dir="ltr">On Wed, Dec 20, 2017 at 12:42 AM, Howard Lovatt <span dir="ltr"><<a href="mailto:howard.lovatt@gmail.com" target="_blank">howard.lovatt@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">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.<div><br></div><div>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.<span class="HOEnZb"><font color="#888888"><br></font></span></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div><div class="h5"><div>On 19 Dec 2017, at 6:44 pm, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Tue, Dec 19, 2017 at 11:15 PM, Howard Lovatt via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><blockquote style="margin:15px 0px;border-left-width:4px;border-left-style:solid;border-left-color:rgb(221,221,221);padding:0px 15px"><div style="margin:0px">As an aside: there seems to be increasingly comments about proposals that say:</div><div style="margin:0px"><br></div><div style="margin:0px"> 1. This was discussed at the evaluation stage and rejected. </div><div style="margin:0px"> 2. This is how it is implemented in the patch.</div><div style="margin:0px"><br></div><div style="margin:0px">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).</div></blockquote></div></blockquote><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><blockquote style="margin:15px 0px;border-left-width:4px;border-left-style:solid;border-left-color:rgb(221,221,221);padding:0px 15px"><div style="margin:0px"><br></div><div style="margin:0px">Anyway gripe over. </div><div style="margin:0px"><span style="background-color:rgba(255,255,255,0)"><br></span></div><div style="margin:0px"><span style="background-color:rgba(255,255,255,0)">Proposal link: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md" target="_blank">https://github.com/apple<wbr>/swift-evolution/blob/master/<wbr>proposals/0192-non-exhaustive-<wbr>enums.md</a></span></div></blockquote><ul style="margin:15px 0px;padding-left:30px"><li style="margin:0px"><span class="m_8698290125088145398gmail-"><p style="margin:0px 0px 15px"><span style="background-color:rgba(255,255,255,0)">What is your evaluation of</span><span style="background-color:rgba(255,255,255,0)"> </span><a dir="ltr" style="background-color:rgba(255,255,255,0)">the proposal</a><span style="background-color:rgba(255,255,255,0)">?</span></p></span><p style="margin:0px 0px 15px"><span style="background-color:rgba(255,255,255,0)">+1/2</span></p><p style="margin:0px 0px 15px"><span style="background-color:rgba(255,255,255,0)">I only give this a half because whilst it is important I can see three issues:</span></p><p style="margin:0px 0px 15px"><span style="background-color:rgba(255,255,255,0)"> 1. It doesn’t seem very Swift like to have a different rule, default non-exhaustive, for public as opposed to non-public. </span></p><p style="margin:0px 0px 15px"><span style="background-color:rgba(255,255,255,0)"> 2. It doesn’t seem very Swift like to have the default the unsafe case. </span></p><p style="margin:0px 0px 15px"><span style="background-color:rgba(255,255,255,0)"> 3. Other languages have better solutions - see below under other languages</span></p></li><li style="margin:0px"><span class="m_8698290125088145398gmail-"><p style="margin:0px 0px 15px"><span style="background-color:rgba(255,255,255,0)">Is the problem being addressed significant enough to warrant a change to Swift?</span></p></span><p style="margin:0px 0px 15px"><span style="background-color:rgba(255,255,255,0)">Yes, Swift ABI compatibility going forwards is important</span></p></li><li style="margin:0px"><span class="m_8698290125088145398gmail-"><p style="margin:0px 0px 15px"><span style="background-color:rgba(255,255,255,0)">Does this proposal fit well with the feel and direction of Swift?</span></p></span><p style="margin:0px 0px 15px"><span style="background-color:rgba(255,255,255,0)">No. As mentioned above different rules for public and a non-safe default don’t see that Swift like. </span></p></li><li style="margin:0px"><span class="m_8698290125088145398gmail-"><p style="margin:0px 0px 15px"><span style="background-color:rgba(255,255,255,0)">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</span></p></span><p style="margin:0px 0px 15px"><span style="background-color:rgba(255,255,255,0)">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. </span></p></li><li style="margin:0px"><span class="m_8698290125088145398gmail-"><p style="margin:0px 0px 15px"><span style="background-color:rgba(255,255,255,0)">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</span></p></span><div>Have followed the discussions. Used enums in Swift and other languages extensively. </div></li></ul><br><div id="m_8698290125088145398gmail-m_4564536098982379360AppleMailSignature">-- Howard.</div><span class="m_8698290125088145398gmail-"><div><br>On 19 Dec 2017, at 12:58 pm, Ted Kremenek <<a href="mailto:kremenek@apple.com" target="_blank">kremenek@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">When replying, please try to keep <span>the proposal</span> link at the top of the message:</p><blockquote style="margin:15px 0px;border-left-width:4px;border-left-style:solid;border-left-color:rgb(221,221,221);padding:0px 15px;color:rgb(119,119,119);font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)"><div style="margin:0px">Proposal link: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md" target="_blank">https://github.com/apple/swift<wbr>-evolution/blob/master/proposa<wbr>ls/0192-non-exhaustive-enums.<wbr>md</a><br>...<br>Reply text<br>...<br>Other replies</div></blockquote><h3 id="m_8698290125088145398gmail-m_4564536098982379360toc_0" style="margin:20px 0px 10px;padding:0px;font-size:18px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">What goes into a review of a proposal?</h3><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">The goal of the review process is to improve <span>the proposal</span> under review through constructive criticism and, eventually, determine the direction of Swift. </p><p style="margin:15px 0px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)">When reviewing a proposal, here are some questions to consider:</p><ul style="margin:15px 0px;padding-left:30px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)"><li style="margin:0px"><p style="margin:0px 0px 15px">What is your evaluation of <span>the proposal</span>?</p></li><li style="margin:0px"><p style="margin:0px 0px 15px">Is the problem being addressed significant enough to warrant a change to Swift?</p></li><li style="margin:0px"><p style="margin:0px 0px 15px">Does this proposal fit well with the feel and direction of Swift?</p></li><li style="margin:0px"><p style="margin:0px 0px 15px">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</p></li><li style="margin:0px"><p style="margin:0px 0px 15px">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</p></li></ul><p style="margin:15px 0px 0px;font-family:Helvetica,arial,sans-serif;background-color:rgb(255,255,255)"></p></div></blockquote></span></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>
</div></blockquote></div></div></div></div></blockquote></div><br></div></div>