Number decoding too strict for use with WKWebView

[eun-ice]

First: Thank you for this library.

However, is it possible to decode a NSNumber that is internally stored as float into an Int64? NSNumber.int64Value works fine, but your library explicitly checks the type and prevents conversion, which is not desired in my use-case.

My use case is that I want to use it to call Swift code in a WKWebView using a WKScriptMessageHandler.

In essence in JavaScript I call

window.webkit.messageHandlers.MyFineHandler.postMessage({val:1000});

WKWebView calls a WKScriptMessageHandler with an NSDictionary, but val is sometimes stored as a float and not as an integer causing the conversion to fail. In JavaScript I don't think I have control over whether the number is a float or an integer.

Minimum reproducer:

struct TestStruct: Codable {
    let val: Int64
}
let dict: NSDictionary = ["val": 6.0 as NSNumber]
let res = try KeyValueDecoder().decode(TestStruct.self, from: dict)

Is this possible to do with your library?

It works for my use-case if I change line 152 of KeyValueDecoder.swift from

-} else if let int64 = (value as? NSNumber)?.getInt64Value() {
+} else if let int64 = (value as? NSNumber)?.int64Value {

[swhitty]

HI @eun-ice and thank you for reporting the issue 🙏🏻.

I agree that this would be handy and have made a change #7 — Please try it out on the main branch.

The change automatically decodes integers from floating point values that do not contain any decimal places
10.0 -> 10

Floating point values that include decimal places and cannot be exactly represented by an Int continue to throw an error
10.5 -> throw DecodingError()

It would be possible to introduce more relaxed decoding rules of numbers rounding to the nearest int but that is a larger change and would need to be made as opt in like the nilDecodingStrategy.

It depends on if there is demand for this kind of behaviour, but I think it would look something like this:

let decoder = KeyValueDecoder()
decoder.intDecodingStragegy = .roundingRule(.up)

enum IntDecodingStrategy {
   case exact //default
   case roundingRule(FloatingPointRoundingRule)
}

[eun-ice]

Hi Swhitty,

thank you so much for this quick and thorough response!

The way I did the conversion before was using

import Foundation

struct TestStruct: Codable {
    let val: Int64
}
let dict: NSDictionary = ["val": 6.0 as NSNumber]

let jsonData = try JSONSerialization.data(withJSONObject: dict, options: [])
let res = try JSONDecoder().decode(TestStruct.self, from: jsonData)

See this fiddle: swiftfiddle.com

In this case 6.1 would also cause an exception, just the way you implemented it with your change.

Since I am replacing this existing code, that does solve the issue for now.

However: I do not trust JS numbers, sometimes they end up being 1.00001, or 0.999999, depending on how the code created these numbers.

Concrete use-case is that I do send pixel coordinates to native code to position UI elements relative to the WebViews content. I can plaster Math.round/Math.ceil everywhere, but I think having the rounding strategy in the library would greatly help in my case.

These are the kinds of bugs you only notice in production with weird display sizes or lots and lots of runtime.

[swhitty]

It was actually fairly straight forward so I have implemented this on main #8.

README.md has been updated to include a new section on Int Decoding Strategy

Values with a fractional part can also be decoded to integers by rounding with any FloatingPointRoundingRule:

let decoder = KeyValueDecoder()
decoder.intDecodingStrategy = .rounded(rule: .toNearestOrAwayFromZero)

// [10, -21, 50]
let values = try decoder.decode([Int].self, from: [10.1, -20.9, 50.00001]),

Please try it out and let me know how it works 🙏🏼.

[eun-ice]

Thank you so much, it works perfectly.

[eun-ice]

A separate question: Can I keep a Decoder around in a class? Do I have to make sure .decode() is not concurrently called?

[swhitty]

FYI I have added a clamping strategy #9 and also renamed IntDecodingStrategy.rounded to IntDecodingStrategy.rounding

[swhitty]

A separate question: Can I keep a Decoder around in a class? Do I have to make sure .decode() is not concurrently called?

KeyValueDecoder / KeyValueEncoder are for the most part threadsafe, .encode() / .decode() place state on the call stack so concurrent calls will not interfere each other.

The types are not marked Sendable but hopefully can be marked as such in Swift 6. I believe current edge case is related to Any where it rely's on the caller not passing any non sendable type.

• func decode<T: Decodable>(_ type: T.Type = T.self, from value: Any)
• var userInfo: [CodingUserInfoKey: Any]

[eun-ice]

The clamping strategy is a very very good idea, I will use that. Thank you so much, I think we can consider this issue closed.

[swhitty]

Excellent. The new release 0.5.0 includes this

[swhitty]

FYI the 0.7.0 release converts the top level KeyValueDecoder / KeyValueEncoder types from class to struct and marks them Sendable.

UserInfo now requires any Sendable values preventing any non sendable values from crossing currency domains:

var userInfo: [CodingUserInfoKey: any Sendable]