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? It seems implementing these would be trivial also for BigInt types. - *Naming: W*hy does popcount retain the term of art? Considering it's relatively obscure it would seem numberOfOneBits or something along those lines would be a more consistent choice. Also, arguably shouldn't it be numberOfLeadingZeroBits? I'm very happy with the inclusion of exposing these instructions btw, I've run into them lacking more than once before! *FullWidth & ReportingOverflow* That's pretty clever there with the trailing argument :). Do you know whether there is any technical reason why we couldn't support a trailing 'argument label' without actual argument directly in the language? If not I might want to write up a proposal for that because if run into wanting this for a longer time. E.g. delegate methods would be a very common case: tableView(_:numberOfSections) is a lot more consistent with all other delegate methods. *Division on Number?* The intro of the proposal puts division under Number, while the detailed design puts it under BinaryInteger, which is it? On Wed, Feb 22, 2017 at 7:39 AM, Max Moiseev via swift-evolution < swift-evolution@swift.org> wrote: > > On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution < > 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.Stride will now conform to > Number and have operators. > > SignedNumber will *not* be the same. It is just the same name. > Stride will have operators, yes. Strideable in general will not, unless > it’s a _Pointer. (you can find the current implementation prototype here > <https://github.com/apple/swift/blob/new-integer-protocols/stdlib/public/core/Stride.swift.gyb> > ). > > > Also minor nitpick, would it be too onerous to require Number.Magnitude to > be Comparable? Currently it’s only Equatable and > ExpressibleByIntegerLiteral. > > Magnitude is supposed to conform to Arithmetic (or Number, or whatever it > ends up being called), but the recursive constraints feature is missing, > therefore we constrained it with the protocols that Arithmetic itself > refines. > > Why would you want Comparable? > > Max > > > _______________________________________________ > 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