Some time ago, it was pointed out that "truncating" would be used only for bit pattern operations. As pointed out on Swift Evolution, this is the only spot where the same term is used for dropping the fractional part of a floating point value; elsewhere, it is always spelled--even in documentation--as "rounded toward zero." This PR updates the usage here to align with existing convention.
It looks like the compiler is having troubles with the pattern when the
non-mutaing operator is defined on the protocol, and delegates to the
mutating version, that is provided by the concrete type. Adding similar
definitions of non-mutating operators to concrete types significantly
speeds up the typechecking of complex expressions, like the one in
the ByteSwap benchmark.
* Give Sequence a top-level Element, constrain Iterator to match
* Remove many instances of Iterator.
* Fixed various hard-coded tests
* XFAIL a few tests that need further investigation
* Change assoc type for arrayLiteralConvertible
* Mop up remaining "better expressed as a where clause" warnings
* Fix UnicodeDecoders prototype test
* Fix UIntBuffer
* Fix hard-coded Element identifier in CSDiag
* Fix up more tests
* Account for flatMap changes
* removing .characters from examples
* beginning new String doc revisions
* improvements to the String Foundation overlay docs
* minor revisions elsewhere
At some point during the implementation of integer protocols these
overloads were necessary to make expressions like `i32 < 0` be faster
and unambiguous.
Now they are no longer necessary, and also cause problems for
expressions like `(u64 - u64) < u64`, where they cause the deprecated
`func - (Strideable, Strideable) -> Stride` be used, which is wrong, as
it will trap in many cases, where `func - (UInt64, UInt64) -> UInt64`
would not.
Fixes: <rdar://problem/31909031>
In Swift 3 shifts used to be defined on the concrete integer types, so
the right-hand-side value in the shift expression could define a type
for the result, as in `1 << i32` would have the type Int32. Swift 4
makes shift operators heterogeneous, so now `1 << i32` will result in an
Int, according to the type of the left-hand-side value, which gets a
default type for integer literals.
Mandatory inlining of a few very frequently used functions caused the
SIL size explosion, which in turn made the inliner use up to 6Gb of
memory to compile the standard library. @inline(__always) helps avoid
that without affecting benchmark results.
Related to: <rdar://problem/31375011>
Conforming types already provide the static bitWidth property. Instance
one can be implemented in a protocol extension.
Resolves: <rdar://problem/30186638>
