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

[Patrick Pijnappel]

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 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170222/0cac4ae7/attachment.html>