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
