@swift-ci create

There are two "bugs" here:

one is an ambiguous reference created by the code as written; specifically the call to

NSNumber.init

instead of the qualified

NSNumber.init(value:)

. The other side of it is the inference of the array literal type. If the array contains a Double it should all be interpreted as a Double.

_ = [0, 0.2].map(NSNumber.init(value:)).map { $0.doubleValue }

The unrecognized selector is the map calling NSNumber() which is invalid and produces a nonsensical result. Not sure why map calls that... which seems like a really gnarly bug.

Ugh, it's specifically picking +[NSValue valueWithNonretainedObject:], which is imported as NSValue.init(nonRetainedObject:). That shouldn't be an inheritable initializer, though, so we definitely have a compiler bug here.

Sadly NSNumber and NSValue have some complicated history in the regards to their initializers but that failure is pretty awful, @belkadan please feel free to re-assign that radar appropriately to a compiler bug.

"it's specifically picking +[NSValue valueWithNonretainedObject:]"
That's interesting. I'm just curious, why it is showed up only in last version of swift? That code behaves correctly in earlier versions. Also, if array is extracted to let constant it works too. Why it picks correct initializer in that case?

I'm not sure what changed from Swift 4.1, but that's important information, so thank you.

Separating the array to a constant means deciding on a type for the array first, without looking at how it's going to be used. In that case, the only information the compiler has is that the elements are 0 and 0.2, and therefore it decides the best type is Array<Double>. When it's all in a single expression, though, the compiler knows that it's going to be passed to an NSNumber initializer, though it doesn't know which one. We're not sure yet why it decided that the initializer that takes Any was better than the one that takes Double, but it did.

Hmm, I see. I think a figured out why it worked in previous versions of swift. Code

_ = NSNumber.init(nonretainedObject: nil).doubleValue

doesn't compile in swift 4.1 with error

 argument labels '(nonretainedObject:)' do not match any available overloads 

and compiles successfully in 4.2 (of course it fails at runtime). So it seems like in swift 4.1 compiler doesn't have any choice other than correct initializer.
Also I checked behaviour of such code:

func f(_ val: Double) { print("double") }
func f(_ val: Any) { print("any") }
[0, 0.2].forEach(f) 

And it prints any in both swift 4.1 and 4.2.

There is another interesting case with nil-coalescing operator

_ = ("1" as String?).map { Float($0) ?? 0 }.map(NSNumber.init).map { $0.doubleValue }

btw, this bug can be exceptionally hard to debug 🙂 Initial case that I reported almost two years ago was met in following circumstances: I had an animation with key times:

let fullDuration: TimeInterval = ...
let firstStepDuration: TimeInterval = ...
let animation = CAKeyframeAnimation(keyPath: #keyPath(CALayer.transform))
animation.keyTimes = [0, firstStepDuration / fullDuration, 1].map(NSNumber.init) // <- it is array of NSValues, not NSNumbers, but we don't know it yet
....
layer.add(animation, forKey: nil)

And of course, given forgiving nature of objc, that code doesn't crash, but it crashes when this animation is actually applying, in another runloop without any traces for above code. To debug this, I wrote down every memory address of created animations, had to inspect and debug assembly of core animation code to find out which animation had wrong values, and then I've found a match with above code.