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

David Sweeris davesweeris at mac.com
Thu Feb 23 11:31:19 CST 2017

> On Feb 23, 2017, at 07:33, plx via swift-evolution <swift-evolution at swift.org> wrote:
> Next quibble: `Magnitude` being defined as the “absolute value” of the underlying type seems a bit nonsensical if e.g. `Number` is intended to be adoptable by complex numbers (let alone quaternions, matrices, and whatnot). What *would* a conforming complex # implementation be expected to return as e.g. `(1-i).magnitude`?

sqrt(2), I believe, or as close to it as can be represented by `Magnitude`. Speaking of which, in my own numerical code, `Magnitude` is typealiased to `Double` specifically because in complex numbers/quaternions/etc, it's almost guaranteed to never be reasonably approximated by an integer (at least for small numbers). What about having a "BuiltinScalar" protocol and setting it there, so that the non-scalar types that we write can define it as `Double` or some other appropriate real-valued type?

> PS: I suspect this ship has *long* sailed but I suspect that it would be better in the long run to go the route of `Addable`, `Multipliable`, etc., and use typealiases to define common groupings thereof; note that once you remove `Magnitude`, the only difference between:
> - `Number` (as defined)
> - `typealias Number = Equatable & ExpressibleByIntegerLiteral & Addable & Multipliable`
> …would be `init?<T : BinaryInteger>(exactly source: T)`.

That's come up before, and IIRC, the decision was that it wasn't necessary for reasons that I no longer recall off the top of my head. Thanks for reminding me about it, though, as I've been meaning to go back and make sure that the reasoning still holds. (I'm sure it does, but part of the point of reviews is to have the community double-check the work to make sure we didn't miss anything, right?)

- Dave Sweeris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170223/cdd1f4d1/attachment.html>

More information about the swift-evolution mailing list