Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 27, 2017, at 11:05 AM, Jordan Rose via swift-evolution > wrote: > > >> On Feb 25, 2017, at 07:06, Ben Rimmington via swift-evolution >> wrote: >> >>

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

+1 to all of this. I completely support the proposal now. Thanks, Jon > On Feb 23, 2017, at 6:05 PM, Ben Cohen via swift-evolution > wrote: > > Hi everyone, > > The core team met and reviewed the discussion of this proposal so far, and > had the following

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 25, 2017, at 8:28 AM, Xiaodi Wu via swift-evolution > wrote: > > I assume that Number being renamed Numeric implies SignedNumber being renamed > SignedNumeric? That is correct. > On Sat, Feb 25, 2017 at 09:06 Ben Rimmington via swift-evolution >

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 25, 2017, at 07:06, Ben Rimmington via swift-evolution > wrote: > > > >> On 24 Feb 2017, at 02:05, Ben Cohen wrote: >> >> Regarding the “Number” protocol: it was

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

I assume that Number being renamed Numeric implies SignedNumber being renamed SignedNumeric? On Sat, Feb 25, 2017 at 09:06 Ben Rimmington via swift-evolution < swift-evolution@swift.org> wrote: > < > https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md > > > >

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On 24 Feb 2017, at 02:05, Ben Cohen wrote: > > Regarding the “Number” protocol: it was felt this is likely to cause > confusion with NSNumber, given the NS-prefix-dropping versions of other >

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On 24 Feb 2017, at 02:05, Ben Cohen via swift-evolution > wrote: > > Regarding the question of the trailing argument to distinguish > overflow-checking vs expanding versions of multiplied: rather than add an > enum or use the void trick in order to do this via

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 24, 2017, at 4:45 PM, Xiaodi Wu wrote: > > That was a deliberate design choice discussed during review of floating point > protocols. Floating point remainder and integer modulo are very different. > Spelling them the same way enables use in generic protocols,

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

That was a deliberate design choice discussed during review of floating point protocols. Floating point remainder and integer modulo are very different. Spelling them the same way enables use in generic protocols, which would be incorrect uses. This was borne out by observation of erroneous uses

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 23, 2017, at 14:44, David Sweeris wrote: > > >>> On Feb 23, 2017, at 2:33 PM, Karl Wagner wrote: >>> >>> >>> On 23 Feb 2017, at 19:40, Max Moiseev wrote: >>> >>> Conformance to Comparable is not required by anything in

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

Hi everyone, The core team met and reviewed the discussion of this proposal so far, and had the following mid-review feedback to relay back to the list: Regarding the “Number” protocol: it was felt this is likely to cause confusion with NSNumber, given the NS-prefix-dropping versions of other

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 23, 2017, at 2:33 PM, Karl Wagner wrote: > > >> On 23 Feb 2017, at 19:40, Max Moiseev wrote: >> >> Conformance to Comparable is not required by anything in the standard >> library. Besides, it is always possible to further constrain your own

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

Sent from my iPhone > On Feb 23, 2017, at 10:40, Max Moiseev wrote: > > Conformance to Comparable is not required by anything in the standard library. That surprises me. Isn't there a sort function or something, or did we change it so they all need a predicate now? > I

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 23, 2017, at 12:43 PM, David Sweeris wrote: > > > > > Sent from my iPhone >> On Feb 23, 2017, at 10:40, Max Moiseev wrote: >> >> Conformance to Comparable is not required by anything in the standard >> library. > > That surprises me. Isn't

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On 23 Feb 2017, at 19:40, Max Moiseev wrote: > > Conformance to Comparable is not required by anything in the standard > library. Besides, it is always possible to further constrain your own code as > in: > Besides FloatingPoint, you mean? Or Collection indexes? Quite a

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

Hi everyone, The core team met and reviewed the discussion of this proposal so far, and had the following mid-review feedback to relay back to the list: Regarding the “Number” protocol: it was felt this is likely to cause confusion with NSNumber, given the NS-prefix-dropping versions of other

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 23, 2017, at 9:54 AM, Karl Wagner wrote: > > >> On 23 Feb 2017, at 18:40, David Sweeris > > wrote: >> >> >> On Feb 22, 2017, at 23:52, Karl Wagner via swift-evolution >>

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On 23 Feb 2017, at 18:40, David Sweeris wrote: > > > On Feb 22, 2017, at 23:52, Karl Wagner via swift-evolution > > wrote: > >> Are there Number types which can’t be Comparable? Complex

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 23, 2017, at 11:31 AM, David Sweeris wrote: > > > On Feb 23, 2017, at 07:33, plx via swift-evolution > wrote: >> >> Next quibble: `Magnitude` being defined as the “absolute value” of the >>

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 22, 2017, at 23:52, Karl Wagner via swift-evolution > wrote: > > Are there Number types which can’t be Comparable? >>> >>> Complex numbers. I believe `Number` is designed to allow a complex number >>> type to conform. >>> > > Magnitude could

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 23, 2017, at 07:33, plx via swift-evolution > wrote: > > Next quibble: `Magnitude` being defined as the “absolute value” of the > underlying type seems a bit nonsensical if e.g. `Number` is intended to be > adoptable by complex numbers (let alone

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

+1 on most of it, with some minor quibbles. First quibble: between `Number` and `Arithmetic` I’d prefer `Arithmetic`; this is 50/50 aesthetics and concern about clarity vis-a-vis `(NS)Number`, `(NS)DecimalNumber`, and so on. Next quibble: `Magnitude` being defined as the “absolute value” of

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

>> >> Are there Number types which can’t be Comparable? >> >> Complex numbers. I believe `Number` is designed to allow a complex number >> type to conform. >> Magnitude could be comparable then. For vectors, matrices and complex numbers, “magnitude” typically refers to a scalar. I don’t

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 22, 2017, at 10:55 AM, Max Moiseev via swift-evolution > wrote: > >> default func multiplied(by other: Self) -> Self // `default` means try >> resolving ambiguities with this version first. The overloaded versions are >> only considered if the

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 22, 2017, at 8:47 AM, David Sweeris via swift-evolution > wrote: > > >> On Feb 22, 2017, at 8:01 AM, Ben Cohen via swift-evolution >> > wrote: >> >> There is another option to avoid the extra

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 22, 2017, at 8:01 AM, Ben Cohen via swift-evolution > wrote: > > There is another option to avoid the extra types, which is to stop trying to > force the disambiguation through argument labels, accept an ambiguous call > and have the context disambiguate:

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

There is another option to avoid the extra types, which is to stop trying to force the disambiguation through argument labels, accept an ambiguous call and have the context disambiguate: // compilation error: ambiguous let x = i.multiplied(by: j) // unambiguously overflow-checked let

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 21, 2017, at 2:04 PM, Karl Wagner wrote: > > >> On 21 Feb 2017, at 21:39, Max Moiseev > > wrote: >> >> >>> On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution >>>

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

On Tue, Feb 21, 2017 at 4:04 PM, Karl Wagner via swift-evolution < swift-evolution@swift.org> wrote: > > On 21 Feb 2017, at 21:39, Max Moiseev wrote: > > > On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution < > swift-evolution@swift.org> wrote: > > I assume the

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On 21 Feb 2017, at 21:39, Max Moiseev wrote: > > >> On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution >> > wrote: >> >> I assume the “SignedNumber” protocol is the same as the existing one in the

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

On Tue, Feb 21, 2017 at 1:51 PM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > For the review, Dave asked me to raise a design question on his behalf, > since he's on vacation. There are places where the proposal introduces > one-case types as a labeling mechanism to

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

On Tue, Feb 21, 2017 at 3:27 PM, Max Moiseev via swift-evolution < swift-evolution@swift.org> wrote: > > On Feb 21, 2017, at 1:15 PM, Patrick Pijnappel > wrote: > > I've followed this for a long time and work a lot with number/big num > related code, and I must say

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 21, 2017, at 1:15 PM, Patrick Pijnappel > wrote: > > I've followed this for a long time and work a lot with number/big num related > code, and I must say I'm really excited about the way this is turning out! > > Popcount & leadingZeroBits > - Placement:

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

I've followed this for a long time and work a lot with number/big num related code, and I must say I'm really excited about the way this is turning out! *Popcount & leadingZeroBits* - *Placement:* What's the rationale behind placing popcount & clz on fixed width integer instead of BinaryInteger?

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution > wrote: > > I assume the “SignedNumber” protocol is the same as the existing one in the > standard library. That is to say, Strideable.Stride will now conform to > Number and have operators.

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 17, 2017, at 7:41 PM, Hugo Hennies via swift-evolution > wrote: > > I would argue against the deprecation of the BitwiseOperations protocol > though. I believe a bitset type would be a good candidate for conformance to > this protocol while at the same

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

For the review, Dave asked me to raise a design question on his behalf, since he's on vacation. There are places where the proposal introduces one-case types as a labeling mechanism to distinguish different operations with otherwise the same argument names, for instance: public enum

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

On Fri, Feb 17, 2017, at 08:45 PM, Joe Groff via swift-evolution wrote: > • What is your evaluation of the proposal? Extremely strong +1. Unlike others, I agree with the proposed deprecation of BitwiseOperations. It's not pulling its own weight under this new model. I encourage other

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> • What is your evaluation of the proposal? +1 I assume the “SignedNumber” protocol is the same as the existing one in the standard library. That is to say, Strideable.Stride will now conform to Number and have operators. Also minor nitpick, would it be too onerous to require

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> > • What is your evaluation of the proposal? +1. Very nice! > • Is the problem being addressed significant enough to warrant a change > to Swift? Yes. > • Does this proposal fit well with the feel and direction of Swift? Very much so. > • If you have used other

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On 18 Feb 2017, at 01:45, Joe Groff via swift-evolution > wrote: > > • What is your evaluation of the proposal? Solid +1, though like others I disagree with deprecating BitwiseOperations, and feel it should be integrated into the protocol hierarchy. >

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> • What is your evaluation of the proposal? Very good. It's a much needed improvement to the language's integer protocols and type hierarchy. I would argue against the deprecation of the BitwiseOperations protocol though. I believe a bitset type would be a good candidate for conformance to

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> • What is your evaluation of the proposal? > Excellent, even better than the first take. Still not sure about the `FullWidth` design, but it'll do. • Is the problem being addressed significant enough to warrant a change to > Swift? > Yes, the previous protocols were confusing and ultimately

[swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

Hello Swift community, The re-review of SE-0104 "Protocol-oriented integers" begins now and runs through February 25, 2017. This proposal was accepted for Swift 3, but was not implemented in time for the release. The revised proposal is available here: