> On Feb 21, 2017, at 2:04 PM, Karl Wagner <[email protected]> wrote: > > >> On 21 Feb 2017, at 21:39, Max Moiseev <[email protected] >> <mailto:[email protected]>> wrote: >> >> >>> On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution >>> <[email protected] <mailto:[email protected]>> 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? >> >> Max >> > > 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
