Revision review: SE-104: Protocol-oriented integers

Evolution Announcements
1

Hi Swift community,

Following feedback during the 4.0 preview, a handful of minor amendments have been suggested to SE-104: Protocol-oriented integers that the core team feels are important to include into 4.0 as they have an impact on source stability.

The review of this amendment begins now and runs through July 24th.

The revised version of the proposal can be found here:

A summary of the amendments to the proposal under review can be found here:

This proposal does not reflect all of the feedback received on SE-104, but instead is a subset that are felt to be valuable _and_ easily achievable in 4.0 even at this fairly late stage of development. There are a few other items that the core team agree should be addressed, but will be deferred to a later version of Swift.

In order to get as much feedback as possible in the remaining time left, we intend to merge these changes on GitHub during the review, and will then fix in-place following the review if any significant new ideas that impact the proposal come up.

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at:

Thanks,

Ben Cohen

Review Manager

2

The revised version of the proposal can be found here:
GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
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.

3

+1 for the removal of ArithmeticOverflow alone.

Charles

···

On Jul 20, 2017, at 5:31 PM, Ben Cohen via swift-evolution <swift-evolution@swift.org> wrote:

Hi Swift community,

Following feedback during the 4.0 preview, a handful of minor amendments have been suggested to SE-104: Protocol-oriented integers that the core team feels are important to include into 4.0 as they have an impact on source stability.

The review of this amendment begins now and runs through July 24th.

The revised version of the proposal can be found here:
https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md

A summary of the amendments to the proposal under review can be found here:
https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md#whats-new-in-this-revision

This proposal does not reflect all of the feedback received on SE-104, but instead is a subset that are felt to be valuable _and_ easily achievable in 4.0 even at this fairly late stage of development. There are a few other items that the core team agree should be addressed, but will be deferred to a later version of Swift.

In order to get as much feedback as possible in the remaining time left, we intend to merge these changes on GitHub during the review, and will then fix in-place following the review if any significant new ideas that impact the proposal come up.

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at:
https://github.com/apple/swift-evolution/blob/master/process.md

Thanks,

Ben Cohen

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

4

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@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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

5

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?

···

On 21 Jul 2017, at 02:01, Xiaodi Wu via swift-evolution <swift-evolution@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@swift.org <mailto:swift-evolution@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.

6

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

On 21 Jul 2017, at 02:01, Xiaodi Wu via swift-evolution < > swift-evolution@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

7

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.

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

On 21 Jul 2017, at 02:01, Xiaodi Wu via swift-evolution < >> swift-evolution@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@swift.org> wrote:

The revised version of the proposal can be found here:

GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

8

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.

···

On 21 Jul 2017, at 17:11, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution@swift.org> wrote:

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

On 21 Jul 2017, at 02:01, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

9

<changing subject line>

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.

This is a great thing to discuss, and I don’t think that there is an iron-clad answer. Keeping swift-evolution effective is a complex problem, because it is highly multi-dimentional space to optimize in. We want to engage the community, encourage people to participate, allow people to push Swift in new directions (when that makes sense) and keep discussions productive and humane. All of this serves a meta goal of harnessing the folks who participate on swift-evolution to make Swift the best language possible.

The constraints are obvious: on most non-trivial topics, there will be some disagreement, so not everyone can be happy. There is only so much engineering time to build cool new things, so it has to be prioritized and divvied up somehow. As you say, it is impossible to make perfect decisions up front, so revisions and iteration are inevitable. Constraints like source and (looming) ABI stability restrict the kinds of changes that can be made. This is made all the more complicated by the fact that a lot of the tradeoffs made are necessarily judgement calls (and occasionally quite subjective), and decisions must be made with imperfect information (e.g. how long it will take to develop a feature). I think it is truly fantastic how engaged and productive swift-evolution is, particularly considering these challenges.

I don’t know how Swift 5 will go, but I would guess that it will be similar to the Swift 4 cycle, but will include changes made by learning from it. If so, it means that Ted will define the overarching themes for the release, to help prioritize effort. This is because currently Apple is paying for the majority of the engineering and they have a completely rationale right to determine how they spend that engineering time. In addition to the major themes, there will be other areas of focus as well (some of which won’t impact swift-evolution, like improvements to build times, performance, and stability).

Development will continue for some period of time, building out new things and a “feature complete” point will be reached. At this point, major changes will be restricted in an effort to stabilize and reduce risk for the release. This doesn’t mean that “no changes” will be made, but as the release grinds inexorably towards its final GM build the scope of changes will be restricted more and more. This is an interesting challenge given that “Beta 1” is usually the first release that goes out to the really broad Swift community, so it is the release that generates the most insight on where the changes have hit their mark or where they have missed. It is incredibly important to enable a feedback loop between folks using the early Swift toolchain builds and the betas so that we can refine and improve things to be the best possible.

Given that we’re very very late in the Swift 4 cycle, this is why Ben is guiding feedback in a certain narrow way (and why Xiaodi is helping to reinforce that guidance). As he says, there are certain changes that just *can’t* be made rationally at this late stage, because big or risky changes require an iteration and feedback cycle, and there isn’t time for it.

Going forward, we’ll all try to communicate what sorts of changes are appropriate at a given time. That said, we can’t make a perfect prediction and guarantee an absolute schedule. I know this can be frustrating, but it is simply the nature of having to make decisions without perfect information.

-Chris

···

On Jul 21, 2017, at 8:12 AM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution@swift.org> wrote:

10

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

On 21 Jul 2017, at 17:11, Nevin Brackett-Rozinsky via swift-evolution < > swift-evolution@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@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@swift.org> wrote:

On 21 Jul 2017, at 02:01, Xiaodi Wu via swift-evolution < >>> swift-evolution@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

11

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?

···

On Jul 21, 2017, at 4:42 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> 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 <swift-evolution@swift.org> wrote:

On 21 Jul 2017, at 17:11, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution@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@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@swift.org> wrote:

On 21 Jul 2017, at 02:01, Xiaodi Wu via swift-evolution <swift-evolution@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

12

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

On 21 Jul 2017, at 17:11, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution@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@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@swift.org> wrote:

On 21 Jul 2017, at 02:01, Xiaodi Wu via swift-evolution <swift-evolution@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

13

To review means to assess or reconsider; even if a new review is only triggered by specific changes, the proposal still needs to be considered as a whole, and I think it's perfectly fine to revisit earlier points, especially if a person's thoughts on those points is part of their assessment of the proposal.

If people have issues with a proposal that a new revision still doesn't address, then I think it's perfectly fair to repeat them, as what was true of the previous version remains true in such cases.

···

On 21 Jul 2017, at 21:04, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

This is a thread to formally _review_ certain changes, not a thread to “talk about” revisions generally.

14

Over the last months, I started two threads to discuss revisions to
SE-0104; these received essentially no reply.

Yes, I'm sorry I didn't have time to reply at the time. These proposed
revisions are, effectively, part of my response to your remarks there.

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.”

I agree. That said, it is all too easy to create an
impression—warranted or otherwise—that the community is insular. It
wouldn't hurt to go out of our way to make sure that, when reminding
someone of what kind of feedback is appropriate to a review, the OP
understands that a forum for their concerns does exist, and that their
concern for the language is appreciated.

Another thing to recognize is that reviews will often lead to discussion
of topics that are connected to, but do not have a direct bearing on the
review. Some of these issues will be important, and surely some will be
frivolous or ill-considered, but they all deserve the same respect. I
don't think this is particularly easy to do well, but ideally we'd
figure out how to redirect these topics without appearing to reprimand.

I predict that switching to Discourse will give us a platform that makes
some of this social engineering work better, but until then we'll have
to take extra care.

···

on Fri Jul 21 2017, Xiaodi Wu <swift-evolution@swift.org> wrote:

On Fri, Jul 21, 2017 at 11:47 David Hart via swift-evolution < > swift-evolution@swift.org> wrote:

On 21 Jul 2017, at 17:11, Nevin Brackett-Rozinsky via swift-evolution < >> swift-evolution@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@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@swift.org> wrote:

On 21 Jul 2017, at 02:01, Xiaodi Wu via swift-evolution < >>>> swift-evolution@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave

15

Haravikk, if you'll refer to the original post in this thread, you'll see
that the core team has not opened up a review of the revised proposal as a
whole; it is explicitly a "review of this amendment."

It is no fun to call people out on this, but I'll do it if no one else
will. If someone starts a conversation to talk about X in a public forum,
anyone is free to join that conversation to talk about X or not to do so.
Surely, we can all agree that it's a breach of etiquette anywhere, in any
forum, to join that conversation with the purpose of talking about Y.
Generally, it's good manners and not "policing" for any participant who's
interested in talking or hearing about X to say to that other person, "I'm
sorry, the topic at the moment is X." That doesn't mean that one person is
better than the other in any way, but it's also not an invitation to start
a debate as to whether the topic at the moment really is X or Y.

···

On Fri, Jul 21, 2017 at 4:07 PM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote:

> On 21 Jul 2017, at 21:04, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:
>
> This is a thread to formally _review_ certain changes, not a thread to
“talk about” revisions generally.

To review means to assess or reconsider; even if a new review is only
triggered by specific changes, the proposal still needs to be considered as
a whole, and I think it's perfectly fine to revisit earlier points,
especially if a person's thoughts on those points is part of their
assessment of the proposal.

If people have issues with a proposal that a new revision still doesn't
address, then I think it's perfectly fair to repeat them, as what was true
of the previous version remains true in such cases.

16

Public forums are helpful, but they are also hard and sometimes frustrating. I am nobody to say how anyone should talk in them, so please don't take this the wrong way.

While the intention of avoiding sidetracking is loable, maybe we could be a bit more careful with the wording. So instead of saying "this is not the place" we can say "can you open a separate thread to talk about your concerns?". Both avoid highjacking, but the second promotes further contributions.

Also, funnily enough, this review thread seems highjacked by this other topic.

···

Sent from my iPhone

On 21 Jul 2017, at 23:57, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

It is no fun to call people out on this, but I'll do it if no one else will. If someone starts a conversation to talk about X in a public forum, anyone is free to join that conversation to talk about X or not to do so. Surely, we can all agree that it's a breach of etiquette anywhere, in any forum, to join that conversation with the purpose of talking about Y. Generally, it's good manners and not "policing" for any participant who's interested in talking or hearing about X to say to that other person, "I'm sorry, the topic at the moment is X." That doesn't mean that one person is better than the other in any way, but it's also not an invitation to start a debate as to whether the topic at the moment really is X or Y.

--
Víctor Pimentel

17

Indeed, this thread has been derailed. I should ask myself to open a
separate thread to talk about these concerns :)

···

On Sat, Jul 22, 2017 at 06:16 Víctor Pimentel <vpimentel@tuenti.com> wrote:

Sent from my iPhone
> On 21 Jul 2017, at 23:57, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:
>
> It is no fun to call people out on this, but I'll do it if no one else
will. If someone starts a conversation to talk about X in a public forum,
anyone is free to join that conversation to talk about X or not to do so.
Surely, we can all agree that it's a breach of etiquette anywhere, in any
forum, to join that conversation with the purpose of talking about Y.
Generally, it's good manners and not "policing" for any participant who's
interested in talking or hearing about X to say to that other person, "I'm
sorry, the topic at the moment is X." That doesn't mean that one person is
better than the other in any way, but it's also not an invitation to start
a debate as to whether the topic at the moment really is X or Y.

Public forums are helpful, but they are also hard and sometimes
frustrating. I am nobody to say how anyone should talk in them, so please
don't take this the wrong way.

While the intention of avoiding sidetracking is loable, maybe we could be
a bit more careful with the wording. So instead of saying "this is not the
place" we can say "can you open a separate thread to talk about your
concerns?". Both avoid highjacking, but the second promotes further
contributions.

Also, funnily enough, this review thread seems highjacked by this other
topic.

--
Víctor Pimentel