On Tue, Feb 21, 2017 at 4:04 PM, Karl Wagner via swift-evolution < [email protected]> wrote:
> > On 21 Feb 2017, at 21:39, Max Moiseev <[email protected]> wrote: > > > On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution < > [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! > > I think it would be worth including Strideable in the “big picture” in the > proposal/manifesto, showing how it fits in.. > > > 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? > Complex numbers. I believe `Number` is designed to allow a complex number type to conform. > > - Karl > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
