<div dir="ltr">Hello Joe,<div>I wanted to ask kindly if it would be possible that the core team adds to the rationale the design decision behind </div><div><pre style="box-sizing:border-box;font-family:sfmono-regular,consolas,"liberation mono",menlo,courier,monospace;font-size:13.6px;margin-top:0px;margin-bottom:0px;font-stretch:normal;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(246,248,250);border-radius:3px;word-break:normal;color:rgb(36,41,46)"> <span class="gmail-pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">associatedtype</span> <span class="gmail-pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">Magnitude</span> : <span class="gmail-pl-e" style="box-sizing:border-box;color:rgb(121,93,163)"><span class="gmail-pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">Equatable</span></span>, <span class="gmail-pl-e" style="box-sizing:border-box;color:rgb(121,93,163)"><span class="gmail-pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">ExpressibleByIntegerLiteral</span></span></pre></div><div>being not comparable. It was pointed out by several reviewers that it is against all intuition that a scalar is not comparable and therefore pretty much useless.</div><div><br></div><div>It would be great if you could add the thoughts of the core team regarding this to the rationale to document the reasons behind it.</div><div><br></div><div>Kind Regards,</div><div>Björn</div><div><br></div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 2, 2017 at 1:50 AM, Joe Groff via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Proposal link: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md" target="_blank">https://github.com/<wbr>apple/swift-evolution/blob/<wbr>master/proposals/0104-<wbr>improved-integers.md</a><div><br></div><div>The re-review of SE-0104 ran from February 17...25, 2017. The proposal is <b>accepted</b> with the following revisions:</div><div><br></div><div>- The root `Number` protocol should be renamed `Numeric`.</div><div>- Instead of using single-case enums as mock trailing argument labels, the `FullWidth` and `ReportingOverflow` variants should include that information in their basename:</div><div><br></div><div><span class="m_4328981600448082971Apple-tab-span" style="white-space:pre-wrap"> </span>multipliedFullWidth(by:)</div><div><span class="m_4328981600448082971Apple-tab-span" style="white-space:pre-wrap"> </span>dividingFullWidth(_:)</div><div><br></div><div><span class="m_4328981600448082971Apple-tab-span" style="white-space:pre-wrap"> </span>addingReportingOverflow(_:)</div><div><span class="m_4328981600448082971Apple-tab-span" style="white-space:pre-wrap"> </span>subtractingReportingOverflow(_<wbr>:)</div><div><span class="m_4328981600448082971Apple-tab-span" style="white-space:pre-wrap"> </span>multipliedReportingOverflow(<wbr>by:)</div><div><span class="m_4328981600448082971Apple-tab-span" style="white-space:pre-wrap"> </span>dividedReportingOverflow(by:)</div><div><br></div><div>- `popcount` should use the unabbreviated name `populationCount`.</div><div><br></div><div>The core team also observed that the proposed endianness-handling interfaces deserve further thought. In almost every known little-, big-, or mixed-endian format, converting to and from another endian are symmetric operations (going to and from big endian are the same operation, as are going to and from little endian), so there is no need for both sets of operations to be independent protocol requirements. The core team accepts the proposal as is for now, since it's a small corner of the larger proposal, but asks the authors for a follow-up proposal in this space.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Joe</div></font></span></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>