> 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] <mailto:[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] <mailto:[email protected]>> wrote: > >> On 21 Jul 2017, at 02:01, Xiaodi Wu via swift-evolution >> <[email protected] <mailto:[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] <mailto:[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 >> >> <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] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <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
