[swift-evolution] [swift-evolution-announce] Revision review: SE-104: Protocol-oriented integers

[Xiaodi Wu]

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 <
swift-evolution at swift.org> wrote:

> On 21 Jul 2017, at 17:11, Nevin Brackett-Rozinsky via swift-evolution <
> swift-evolution at swift.org> 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 <
> swift-evolution at swift.org> 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 <
>> swift-evolution at swift.org> wrote:
>>
>>>
>>> On 21 Jul 2017, at 02:01, Xiaodi Wu via swift-evolution <
>>> swift-evolution at swift.org> 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 <
>>> swift-evolution at swift.org> 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
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170721/5a73eaab/attachment.html>