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

[Max Moiseev]

> On Feb 21, 2017, at 1:15 PM, Patrick Pijnappel <patrickpijnappel at 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170221/225fc430/attachment.html>