The function's definition is "Returns a random value that is less than the given upper bound," which cannot possibly be satisfied with upperBound == 0; previously the function returned zero, which was a bug.
Fix Hashable conformance of standard integer types so that the number of bits they feed into hasher is exactly Self.bitWidth.
This was intended to be part of SE-0206. However, it would have introduced additional issues with AnyHashable. The custom AnyHashable representations introduced in the previous commit unify hashing for numeric types, eliminating the problem.
AnyHashable has numerous edge cases where two AnyHashable values compare equal but produce different hashes. This breaks Set and Dictionary invariants and can cause unexpected behavior and/or traps. This change overhauls AnyHashable's implementation to fix these edge cases, hopefully without introducing new issues.
- Fix transitivity of ==. Previously, comparisons involving AnyHashable values with Objective-C provenance were handled specially, breaking Equatable:
let a = (42 as Int as AnyHashable)
let b = (42 as NSNumber as AnyHashable)
let c = (42 as Double as AnyHashable)
a == b // true
b == c // true
a == c // was false(!), now true
let d = ("foo" as AnyHashable)
let e = ("foo" as NSString as AnyHashable)
let f = ("foo" as NSString as NSAttributedStringKey as AnyHashable)
d == e // true
e == f // true
d == f // was false(!), now true
- Fix Hashable conformance for numeric types boxed into AnyHashable:
b == c // true
b.hashValue == c.hashValue // was false(!), now true
Fixing this required adding a custom AnyHashable box for all standard integer and floating point types. The custom box was needed to ensure that two AnyHashables containing the same number compare equal and hash the same way, no matter what their original type was. (This behavior is required to ensure consistency with NSNumber, which has not been preserving types since SE-0170.
- Add custom AnyHashable representations for Arrays, Sets and Dictionaries, so that when they contain numeric types, they hash correctly under the new rules above.
- Remove AnyHashable._usedCustomRepresentation. The provenance of a value should not affect its behavior.
- Allow AnyHashable values to be downcasted into compatible types more often.
- Forward _rawHashValue(seed:) to AnyHashable box. This fixes AnyHashable hashing for types that customize single-shot hashing.
https://bugs.swift.org/browse/SR-7496
rdar://problem/39648819
* Make FloatingPoint require that Self.Magnitude == Self
We didn't have the where clause to express this constraint at the time that the FloatingPoint protocol was implemented, but we do now. This is not a semantic change to FloatingPoint, which has always bound IEEE-754 arithmetic types, for which this constraint would necessarily hold, but it does effect the type system.
For example, currently the following function does not type check:
~~~~
func foo<T>(x: T) -> T where T: FloatingPoint {
var r = x.remainder(dividingBy: 1)
return r.magnitude
}
~~~~
with this change, it compiles correctly.
Having done this, we no longer need to have a separate `abs` defined on FloatingPoint; we can use the existing function defined on `SignedNumeric` instead. Additionally mark the global `fabs` defined in the platform C module deprecated in favor of the Swift `abs`; we don't need to carry two names for this function going forward.
We would like to eventually extend Array, Dictionary, and Set to support move-only element types when the language does. To that end, we need to get the `consuming`-ness of protocol requirements on Sequence, Collection, and related protocols right for forward compatibility so that a future version of Swift that extends these types to support move-only data structures remains ABI- and API-compatible with older versions of the language. Mark requirements as `__consuming` where it would be necessary for a move-only implementation of one of these types.
- Move deprecated declarations into a separate deprecated extension
(suppresses tghe warning)
- Mark an initializer from CharacterView as deprecated
Addresses: <rdar://problem/40625231>
Add some fast paths to String.init(decoding:as:) for inputs of
contiguously stored UTF-8 code units. Dramatically speeds up creation
when the String happens to be ASCII and we can form more small
strings.
