mirror of
https://github.com/apple/swift.git
synced 2025-12-14 20:36:38 +01:00
85d488d461
The standard library has two versions of the `abs(_:)` function: ``` func abs<T : SignedNumeric>(_ x: T) -> T where T.Magnitude == T func abs<T : SignedNumeric & Comparable>(_ x: T) -> T ``` The first is more specialized than the second because `T.Magnitude` is known to conform to `Comparable`. Indeed, it’s a more specialized implementation that returns `magnitude`. However, this overload behaves oddly: in the expression `abs(-8)`, the type checker will pick the first overload because it is more specialized. That’s a general guiding principle for overloading: pick the most specialized overload that works. However, to select that overload, it needs to pick a type for the literal “8” for which that overload works, and it chooses `Double`. The “obvious” answer, `Int`, doesn’t work because `Int.Magnitude == UInt`. There is a conflict between the two rules, here: we prefer more-specialized overloads (but we’ll fall back to less-specialized if those don’t work) and we prefer to use `Int` for integer literals (but we’ll fall back to `Double` if it doesn’t work). We have a few options from a type-checker perspective: 1. Consider the more-specialized-function rule to be more important 2. Consider the integer-literals-prefer-`Int` rule to be more important 3. Call the result ambiguous and make the user annotate it The type checker currently does #1, although at some point in the past it did #2. Moving forward, #1 is a better choice because it prunes the number of overloads that need to be considered: if the more-specialized overload succeeds its type-check, the others need not be considered. It’s also easier to reason about than the literal-scoring approach, because there can be a direct definition for “more specialized than” that can be reasoned about. I think we should dodge the issue by removing the more-specialized version of `abs(_:)`. Its use of `magnitude` seems unlikely to provide a significant performance benefit, and the presence of overloading either forces us to consider both overloads always (which is bad for type checker performance) or accept the regression that `abs(-8)` is `Double`. Better to eliminate the overloading and, if needed in the future, find a better way to introduce the more-specialized implementation without it being a separate signature. Fixes rdar://problem/42345366.
64 lines
1.8 KiB
Swift
64 lines
1.8 KiB
Swift
// RUN: %target-build-swift %s -swift-version 4 -typecheck
|
|
|
|
|
|
func byteswap_n(_ a: UInt64) -> UInt64 {
|
|
return ((a & 0x00000000000000FF) &<< 56) |
|
|
((a & 0x000000000000FF00) &<< 40) |
|
|
((a & 0x0000000000FF0000) &<< 24) |
|
|
((a & 0x00000000FF000000) &<< 8) |
|
|
((a & 0x000000FF00000000) &>> 8) |
|
|
((a & 0x0000FF0000000000) &>> 24) |
|
|
((a & 0x00FF000000000000) &>> 40) |
|
|
((a & 0xFF00000000000000) &>> 56)
|
|
}
|
|
|
|
|
|
// expression should not be too complex
|
|
func radar31845712(_ i: Int, _ buffer: [UInt8]) {
|
|
_ = UInt64(buffer[i])
|
|
| (UInt64(buffer[i + 1]) &<< 8)
|
|
| (UInt64(buffer[i + 2]) &<< 16)
|
|
| (UInt64(buffer[i + 3]) &<< 24)
|
|
| (UInt64(buffer[i + 4]) &<< 32)
|
|
| (UInt64(buffer[i + 5]) &<< 40)
|
|
| (UInt64(buffer[i + 6]) &<< 48)
|
|
| (UInt64(buffer[i + 7]) &<< 56)
|
|
}
|
|
|
|
// expression should not be too complex
|
|
func radar32149641() {
|
|
func from(bigEndian input: UInt32) -> UInt32 {
|
|
var val: UInt32 = input
|
|
return withUnsafePointer(to: &val) { (ptr: UnsafePointer<UInt32>) -> UInt32 in
|
|
return ptr.withMemoryRebound(to: UInt8.self, capacity: 4) { data in
|
|
return (UInt32(data[3]) &<< 0) |
|
|
(UInt32(data[2]) &<< 8) |
|
|
(UInt32(data[1]) &<< 16) |
|
|
(UInt32(data[0]) &<< 24)
|
|
}
|
|
}
|
|
}
|
|
}
|
|
|
|
func homogeneousLookingShiftAndAMask(_ i64: Int64) {
|
|
_ = (i64 >> 8) & 0xFF
|
|
}
|
|
|
|
func negativeShift(_ u8: UInt8) {
|
|
_ = (u8 << -1)
|
|
}
|
|
|
|
func sr5176(description: String = "unambiguous Int32.init(bitPattern:)") {
|
|
_ = Int32(bitPattern: 0) // should compile without ambiguity
|
|
}
|
|
|
|
func sr6634(x: UnsafeBufferPointer<UInt8>) -> Int {
|
|
return x.lazy.filter { $0 > 127 || $0 == 0 }.count // should be unambiguous
|
|
}
|
|
|
|
// abs of an integer literal
|
|
func returnIntAbs() -> Int {
|
|
let x = abs(-8)
|
|
return x
|
|
}
|