[swift-evolution] [Accepted] SE-0104: Protocol-oriented integers
bjoern.forster at googlemail.com
Thu Mar 2 08:22:23 CST 2017
I wanted to ask kindly if it would be possible that the core team adds to
the rationale the design decision behind
associatedtype Magnitude : Equatable, ExpressibleByIntegerLiteral
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
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.
On Thu, Mar 2, 2017 at 1:50 AM, Joe Groff via swift-evolution <
swift-evolution at swift.org> wrote:
> Proposal link: https://github.com/apple/swift-evolution/blob/
> The re-review of SE-0104 ran from February 17...25, 2017. The proposal is
> *accepted* with the following revisions:
> - The root `Number` protocol should be renamed `Numeric`.
> - Instead of using single-case enums as mock trailing argument labels, the
> `FullWidth` and `ReportingOverflow` variants should include that
> information in their basename:
> - `popcount` should use the unabbreviated name `populationCount`.
> 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.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution