<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>To play devil’s advocate, what if their concern was initially unheeded, and now experience has revealed that their concern was in fact valid all along and more serious than other people realized it would be at the time it was initially raised – surely then it would be appropriate to re-raise the concern?</div><div><br>On Jul 21, 2017, at 4:42 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div>Over the last months, I started two threads to discuss revisions to SE-0104; these received essentially no reply. I’m quite sure others have touched on these topics too. This is a thread to formally _review_ certain changes, not a thread to “talk about” revisions generally.<br><br>With respect to the specific issues raised: revisions are opportunities, as was well said, to apply new insights gained from experience. They are _not_ meant to reopen the floor for anyone who already voiced their opinion on the original proposal simply to restate their opposition to particular changes. While every_one_ should certainly be welcomed to the community, that does not mean that every kind of participation should be. I don’t think we should be shy about saying, “I’m sorry, this is not a helpful comment at this time and place.”<br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 21, 2017 at 11:47 David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On 21 Jul 2017, at 17:11, Nevin Brackett-Rozinsky via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-2998916497441769658Apple-interchange-newline"><div><div dir="ltr">The updates look fine and reasonable to me.<div><br></div><div>That said, I think it is highly important that we have clarity regarding what *is* the proper time, method, and process for raising issues with and suggesting modifications to approved proposals. If there is one thing we have learned recently it is that sometimes a proposed change sounds good and gets approved (110, 25, etc.) which subsequently turns out to have unintended detrimental consequences.</div><div><br></div><div>We are not infallible, and there will certainly be times in the future when we think a change is good in theory, but then after experiencing it in practice we recognize it has problems. When that happens—and happen it will—we need to be able to correct our course. And it is far better to fix such things before they are released to the wider world.</div><div><br></div><div>I don’t know if the issues Howard raises rise to that level. I haven’t tested out the new integer protocols, so I am not in a position to weigh the merits of the claim. Certainly in the abstract “signum” sounds like it is asking for a property of the number, and not asking the number to do something function-like, but I defer to those who use it in practice.</div><div><br></div><div>The point is, rather than shutting down discussion by saying “it has already been approved” and “this is not the place for discussing that”, it would greatly behoove the Swift Evolution process to have an established method for recommending changes to already-approved proposals. We have this time interval between when a proposal is accepted and when it appears in a public release of the language, and it seems only natural to use it as a beta-testing period.</div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>I think it also important that we encourage people to participate and not drive them away. If we decide that a thread talking about revisions to a proposal is not the right place to discussion other grievances about the same proposal, perhaps a new thread is the right place.</div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div dir="ltr"><div>That way we can fix problems we encounter before they become permanent, and similarly we can make minor changes which are obvious improvements we somehow overlooked during the initial review.</div><div><br></div><div>Nevin</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 21, 2017 at 7:50 AM, Xiaodi Wu via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I understand you feel this way, but this thread is a formal review of specific amendments to SE-0104. Those amendments are, again, the following:<br><br>* Reorganizing shift operators<br>* Removing the ArithmeticOverflow type in favor of using a simple Bool<br>* Changing BinaryInteger's initializers that convert from floating point values<br>* Renaming BinaryInteger's init(extendingOrTruncating:)<br><br><div class="gmail_quote"><div><div class="m_-2998916497441769658h5"><div dir="ltr">On Fri, Jul 21, 2017 at 02:08 Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-2998916497441769658h5"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On 21 Jul 2017, at 02:01, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-2998916497441769658m_-1249778600790985709m_1929092913309989426Apple-interchange-newline"><div>Hi Howard,<br><br>The removal of BitwiseOperations is not under review here; that, like signum(), has been considered twice and approved twice, and has not been revised.<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 20, 2017 at 19:36 Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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 style="word-wrap:break-word;line-break:after-white-space"><div>The revised version of the proposal can be found here:</div><div><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md</a></div><div><br></div><div><span class="m_-2998916497441769658m_-1249778600790985709m_1929092913309989426m_2994816141908992432m_1574666041005850135Apple-tab-span" style="white-space:pre-wrap"> </span>• What is your evaluation of the proposal?<br></div></div></blockquote></div></div></div><div dir="ltr"><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 style="word-wrap:break-word;line-break:after-white-space"></div></blockquote><div><br></div><div>Overall +1. Two reservations:</div><div><br></div><div> 1. Functions like `signum()` that return a property would read better as a property!</div><div> 2. I have found `BitwiseOperations` useful as an extension to both Bool and Set and for a custom set type. Therefore would prefer its retention and even more preferably that Bool and Set implement it.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><span class="m_-2998916497441769658m_-1249778600790985709m_1929092913309989426m_2994816141908992432m_1574666041005850135Apple-tab-span" style="white-space:pre-wrap"> </span>• Is the problem being addressed significant enough to warrant a change to Swift?<br></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Yes, generic representation of integers is useful.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><span class="m_-2998916497441769658m_-1249778600790985709m_1929092913309989426m_2994816141908992432m_1574666041005850135Apple-tab-span" style="white-space:pre-wrap"> </span>• Does this proposal fit well with the feel and direction of Swift?<br></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Yes, particularly the re-arrangment of the protocol hierarchy is in keeping with the rest of the restructuring of the standard library.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><span class="m_-2998916497441769658m_-1249778600790985709m_1929092913309989426m_2994816141908992432m_1574666041005850135Apple-tab-span" style="white-space:pre-wrap"> </span>• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Yes, many languages I use allow generic numeric functions to be written and I write my own numeric functions and will therefore use these protocols.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><span class="m_-2998916497441769658m_-1249778600790985709m_1929092913309989426m_2994816141908992432m_1574666041005850135Apple-tab-span" style="white-space:pre-wrap"> </span>• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Quick read, but have pulled my hair out trying to write generic stuff in Swift as it stands now.</div></div></div></div></blockquote></div></div></blockquote><br></div></div><div style="word-wrap:break-word"><div>I agree with Howard on both points; In particular I've never agreed with the removal of BitwiseOperations, and believe it to be a mistake. What's the point of making Integers more protocol-oriented if you then go about getting rid of useful protocols?</div></div></div></div><span>_______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
</span></blockquote></div>
<br>_______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
_______________________________________________<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" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div></div>_______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>