<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Proposal link:&nbsp;<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><div class=""><br class=""></div><div class="">The re-review of SE-0104 ran from&nbsp;February 17...25, 2017. The proposal is <b class="">accepted</b>&nbsp;with the following revisions:</div><div class=""><br class=""></div><div class="">- The root `Number` protocol should be renamed `Numeric`.</div><div class="">- 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 class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>multipliedFullWidth(by:)</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>dividingFullWidth(_:)</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>addingReportingOverflow(_:)</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>subtractingReportingOverflow(_:)</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>multipliedReportingOverflow(by:)</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>dividedReportingOverflow(by:)</div><div class=""><br class=""></div><div class="">- `popcount` should use the unabbreviated name `populationCount`.</div><div class=""><br class=""></div><div class="">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><div class=""><br class=""></div><div class="">-Joe</div></body></html>