<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">+1 on most of it, with some minor quibbles.</div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">First quibble: between `Number` and `Arithmetic` I’d prefer `Arithmetic`; this is 50/50 aesthetics and concern about clarity vis-a-vis `(NS)Number`, `(NS)DecimalNumber`, and so on.</div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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`? For the intended use this seems like it needs to be moved out of the basic `Number`/`Arithmetic` protocol into a new protocol.</div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Final quibble: is there an official stance as to whether or not `Number/`Arithmetic` is allowed to have non-commutative multiplication? I see would prefer any policy on this be explicitly documented.</div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">If `Number`/`Arithmetic` *is* intended to allow adopters with non-commutative multiplication, then it’s seemingly missing an overridable method:</div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">- this exists: `x *= y` (presumably equivalent to `x = x * y`)</div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">- this doesn't: `x =* y` (presumably equivalent to one of `x = y * x` *or* `y = x * y`, your preference)</div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">…(alternative operator names are fine, the important bit is an in-place multiplication-from-the-left). Not necessary, but still nice to have for non-commutative adoptees.</div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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:</div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">- `Number` (as defined)</div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">- `typealias Number = Equatable & ExpressibleByIntegerLiteral & Addable & Multipliable`</div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">…would be `init?<T : BinaryInteger>(exactly source: T)`.</div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Although this is an extra method and thus extra “semantics”, I think there’s a perfectly-reasonable argument that—at least informally—the *semantics* of `init?<T : BinaryInteger>(exactly source: T)` are already-implied by the adoption of `ExpressibleByIntegerLiteral`; in fact, are there any types that *could* reasonably adopt `ExpressibleByIntegerLiteral` but *could not* reasonably implement `init?<T : BinaryInteger>(exactly source: T)`? </div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Anyways, that’s my 2c on this: the Integer-related aspects seem fine, but I have quibbles vis-a-vis the foundational protocol.</div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Feb 17, 2017, at 7:45 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hello Swift community,<br class=""><br class="">The re-review of SE-0104 "Protocol-oriented integers" begins now and runs through February 25, 2017. This proposal was accepted for Swift 3, but was not implemented in time for the release. The revised proposal is available here:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md</a><br class=""><br class=""><div class="">Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div><div class=""><br class="">or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Proposal link:<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md</a><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Reply text<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Other replies<br class=""><br class=""></div><div class=""><b class="">What goes into a review?</b><br class=""><br class="">The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:<br class=""><br class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• What is your evaluation of the proposal?<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Does this proposal fit well with the feel and direction of Swift?<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class=""></div><div class=""><br class=""></div>More information about the Swift evolution process is available at<br class=""><br class=""><a href="https://github.com/apple/swift-evolution/blob/master/process.md" class="">https://github.com/apple/swift-evolution/blob/master/process.md</a><br class=""><br class=""></div><div class="">Thank you,<br class=""><br class="">-Joe Groff<br class="">Review Manager</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></div></body></html>