> 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.
Yes, Xiaodi I understand you are trying to help, but I find that sometimes you do talk down to other posters a bit vocally policing what should or not be said. Sent from my iPhone > On 21 Jul 2017, at 21:04, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > > 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. > > 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.” > On Fri, Jul 21, 2017 at 11:47 David Hart via swift-evolution > <[email protected]> wrote: >>> On 21 Jul 2017, at 17:11, Nevin Brackett-Rozinsky via swift-evolution >>> <[email protected]> wrote: >>> >>> The updates look fine and reasonable to me. >>> >>> 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. >>> >>> 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. >>> >>> 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. >>> >>> 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. >> >> 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. >> >>> 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. >>> >>> Nevin >>> >>> >>>> On Fri, Jul 21, 2017 at 7:50 AM, Xiaodi Wu via swift-evolution >>>> <[email protected]> wrote: >>>> 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: >>>> >>>> * Reorganizing shift operators >>>> * Removing the ArithmeticOverflow type in favor of using a simple Bool >>>> * Changing BinaryInteger's initializers that convert from floating point >>>> values >>>> * Renaming BinaryInteger's init(extendingOrTruncating:) >>>> >>>>> On Fri, Jul 21, 2017 at 02:08 Haravikk via swift-evolution >>>>> <[email protected]> wrote: >>>>> >>>>>> On 21 Jul 2017, at 02:01, Xiaodi Wu via swift-evolution >>>>>> <[email protected]> wrote: >>>>>> >>>>>> Hi Howard, >>>>>> >>>>>> The removal of BitwiseOperations is not under review here; that, like >>>>>> signum(), has been considered twice and approved twice, and has not been >>>>>> revised. >>>>>> >>>>>> On Thu, Jul 20, 2017 at 19:36 Howard Lovatt via swift-evolution >>>>>> <[email protected]> wrote: >>>>>>>> The revised version of the proposal can be found here: >>>>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md >>>>>>>> >>>>>>>> • What is your evaluation of the proposal? >>>>>>> >>>>>>> >>>>>>> Overall +1. Two reservations: >>>>>>> >>>>>>> 1. Functions like `signum()` that return a property would read better >>>>>>> as a property! >>>>>>> 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. >>>>>>> >>>>>>>> • Is the problem being addressed significant enough to warrant >>>>>>>> a change to Swift? >>>>>>> >>>>>>> Yes, generic representation of integers is useful. >>>>>>> >>>>>>>> • Does this proposal fit well with the feel and direction of >>>>>>>> Swift? >>>>>>> >>>>>>> Yes, particularly the re-arrangment of the protocol hierarchy is in >>>>>>> keeping with the rest of the restructuring of the standard library. >>>>>>> >>>>>>>> • If you have used other languages or libraries with a similar >>>>>>>> feature, how do you feel that this proposal compares to those? >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>>> • How much effort did you put into your review? A glance, a >>>>>>>> quick reading, or an in-depth study? >>>>>>> >>>>>>> Quick read, but have pulled my hair out trying to write generic stuff >>>>>>> in Swift as it stands now. >>>>> >>>>> 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? >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
