> On Feb 21, 2017, at 1:15 PM, Patrick Pijnappel <patrickpijnap...@gmail.com> > 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 placing popcount & clz on fixed > width integer instead of BinaryInteger? It seems implementing these would be > trivial also for BigInt types. Arbitrary sized signed -1 can have different popcount depending on the underlying buffer length (if there is a buffer) even if it’s the same type and the same value. Same with leading zeros, as the underlying representation is unbounded on the more significant side.
> - Naming: Why 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. The thinking was something like: people who know it, know it by this name and will be a little annoyed, people who don’t know what it is, and simply want their stack overflow snippet to work, will not be able to identify it under any other name. So a non-term-of-art name would not really benefit anyone, other than our naming guidelines. > Also, arguably shouldn't it be numberOfLeadingZeroBits? There is countLeadingZeroBits for that. > I'm very happy with the inclusion of exposing these instructions btw, I've > run into them lacking more than once before! What would you say about popcount being a protocol requirement? If you’ve needed it, was it in the generic context or on concrete types? > > 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. Joe recently sent an email on behalf of Dave to start this very discussion. > > Division on Number? > The intro of the proposal puts division under Number, while the detailed > design puts it under BinaryInteger, which is it? It is one of the most recent changes, division is *not* in the Number. It was moved down the hierarchy to BinaryInteger. I’ll fix the proposal. Thanks! Max > > On Wed, Feb 22, 2017 at 7:39 AM, Max Moiseev via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution >> <swift-evolution@swift.org <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.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 <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
