The SignedArithmetic protocol provides default implementations for both
negate() and negated(), with negate() calling negated(). This is inconsistent
with the Arithmetic protocol, which provides implementations of the nonmutating
methods that call their mutating counterparts. This flips the implementations
of negate() and negated() so an implementer only has to focus on mutating
methods.
This introduces some important diagnostics to help migration.
Some of the diagnostics that we would like to provide are impossible
on a generic class because they introduce ambiguity.
Renaming UnsafePointer<Void> to UnsafeRawPointer makes extensions and
global operators ambiguous.
We would also like to provide this fix-it on conversion from
UnsafePointer<Void> or UnsafeRawPointer to UnsafePointer<T>
with this message:
Conversion restricted. Use 'assumingMemoryBound(to:)' or 'bindMemory(to:capacity:)'}}
However, that introduces ambiguous overloads that defeat other hueristics.
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
* [stdlib] Introducing the new Arithmetic protocol
* [stdlib] conforming floating point types to the new Arithmetic protocol
* [stdlib] removing AbsoluteValuable conformance from floating point types
* [stdlib] removing the integers prototype
