[swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers
patrickpijnappel at gmail.com
Tue Feb 21 15:15:05 CST 2017
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
*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
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
*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
> Also minor nitpick, would it be too onerous to require Number.Magnitude to
> be Comparable? Currently it’s only Equatable and
> 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
> Why would you want Comparable?
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution