[swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers
moiseev at apple.com
Tue Feb 21 16:54:33 CST 2017
> On Feb 21, 2017, at 2:04 PM, Karl Wagner <razielim at gmail.com> wrote:
>> On 21 Feb 2017, at 21:39, Max Moiseev <moiseev at apple.com <mailto:moiseev at apple.com>> 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>).
> Currently, it’s difficult to work with Strideable because you can calculate distances between them (as type Strideable.Stride), but you can’t add those distances because Strideable.Stride is only constrained to conform to “SignedNumber”, which is a pretty useless protocol.
> In the prototype, Strideable.Stride has now been changed, so it is constrained to “SignedArithmetic” (which, apparently, is to be renamed “SignedNumber”). So essentially, the existing SignedNumber has been re-parented to “Number” and gains operations such as addition. That’s great!
Ah.. I see what you mean. Thanks for the explanation. I think we usually just used Bound : Strideable, Bound.Stride : SignedInteger, but yes, you’re right, it will be simpler now.
> I think it would be worth including Strideable in the “big picture” in the proposal/manifesto, showing how it fits in..
That can be a valuable addition, indeed. Thanks!
>>> 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?
> I suppose that leads me on to the question of why Number itself only requires that conformers be (Equatable & ExpressibleByIntegerLiteral) and does not require that they be Comparable.
> If I must be able to create any “Number" out of thin air with an integer literal, is it not reasonable to also require that I am able to compare two instances?
> Are there Number types which can’t be Comparable?
> - Karl
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution