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

[Xiaodi Wu]

On Tue, Feb 21, 2017 at 3:27 PM, Max Moiseev via swift-evolution <
swift-evolution at swift.org> wrote:

>
> 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: 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.
>
> 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?
>

So I for one have needed it. The question Jordan asked was interesting,
because on reflection I've only needed it so far on concrete types. That
said, in part that must be chalked up to integer generics not being really
usable in the past.

On balance, MHO is that it's worthwhile to make it a protocol requirement
(defaulted of course). It makes sense that all fixed-width integers have a
popcount (and leadingZeroBits), just as they all have a bitWidth. Now, some
fixed-width integers might not have a very optimized way of computing that
popcount, but still. It is not out of the question that one would want to
do some work based on the bits in a generic integer that has a fixed number
of bits.

*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> wrote:
>
>>
>> On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution <
>> 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
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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/0b875b0c/attachment.html>