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: >> >> >> >>> On 24 Feb 2017, at 02:05, Ben Cohe

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 mid-review feedback to relay back t

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

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 felt this is likely to cause >

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 > Foundation

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 arguments, it is better to >

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, which would be > incorr

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 of

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 the standard >>> library. Besides, it is always possible to f

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 F

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 code >> as in: >> > > Besides Floating

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

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: func f(_ x: T) where T.Magnitude : Comparable {} I would argue that adding constraints without solid proof of them being useful and necessary i

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 would argue that addi

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 there a sort function or something, or d

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 lot of stuff, actu

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 F

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

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 > mailto:swift-evolution@swift.org>> wrote: > >> Are there Number types which can’t be Comparable? Complex numbers. I believe `Number` is designed to allow

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 >> underlying type seems a bit nonsensical if e.g. `Number` is

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 be comparable then. For vec

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 quaternions, matrices, and whatnot).

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 the

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 thi

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 type-checker can’t make this version

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> There is another option to avoid the extra types, which is to stop trying to >> force the disambigua

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: > > // compilation error: a

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 (y,overflow

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 >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> I assume the “SignedNumber” proto

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 “SignedNumber” protocol

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> I assume the “SignedNumber” protocol is the same as the existing one in the >> standard library. That is to say, Strideable.S

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 distingu

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 I'm really excited about the wa

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: What's the rationale behind pl

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? I

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. SignedNumber will *not* be the same.

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 time not being an integer at al

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 ReportingOv

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 reviewer

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 Number.Ma

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 l

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. > • Is the problem being add

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 th

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 no

[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: https://github.com/apple/swift-ev