Thanks I will give that a try on Friday when I have the hardware available! 
Posted an issue and will add to that when I have tried, or if the library 
authors can comment on how they use the NSNumber..

> 5. okt. 2016 kl. 19.31 skrev Joe Groff <[email protected]>:
> 
> 
>> On Oct 5, 2016, at 2:30 AM, Lars-Jørgen Kristiansen via swift-users 
>> <[email protected] <mailto:[email protected]>> wrote:
>> 
>> I'm working with a third party API for some external hardware. One of the 
>> functions takes a NSNumber, and it fails to interact correctly with the 
>> hardware if I cast a Float too NSNumber, but works as expected if I use 
>> Double..
>> 
>> I dont know if it is related to NSNumber.stringValue since I dont know what 
>> the third part lib does with the NSNumber, but I noticed this:
>> 
>> let float = 100_000_00 as Float
>> let floatNumber = float as NSNumber
>> 
>> let double = 100_000_00 as Double
>> let doubleNumer = double as NSNumber
>> 
>> hardware.doThing(number: floatNumber as NSNumber) // Hardware does not work
>> hardware.doThing(number: doubleNumer as NSNumber) // Hardware works
>> 
>> // Also noticed this:
>> "\(floatNumber)" // "1e+07"
>> "\(doubleNumer)" // "10000000"
>> 
>> Is this expected behaviour?
> 
> cc'ing Tony and Philippe, who might be able to comment on the intended 
> behavior of NSNumber here. When you cast using `as`, Swift will do the 
> conversion through its Objective-C bridge, and will attempt to use a custom 
> subclass of NSNumber that remembers the exact Swift type it was bridged as, 
> such as Float or Double. There's a small chance your library is making 
> assumptions that it's working with one of the standard NSNumber subclasses 
> used by the Foundation implementation. If you call the NSNumber initializer 
> `NSNumber(value: floatNumber)` instead of using the `as` conversion, you'll 
> get one of these standard NSNumbers instead of a Swift-bridged NSNumber. Try 
> that and see if it works. If using the initializer does indeed fix the 
> problem, we'd appreciate a bug report, so we can investigate fixing the 
> incompatibility with our NSNumber subclasses.
> 
> -Joe

_______________________________________________
swift-users mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-users

Reply via email to