We should consider having a JSONCompatible protocol that is conformed to by things like String, Int, etc, as a replacement for the family of JSON.init(_:) initializers. We could then have a single JSON.init(_:) initializer that is generic using this protocol.
The goal here is to sidestep the type-checking complexity issue when using a bunch of JSON(foo) calls in the same expression.
We should also do some microbenchmarks on performance, because generics are implemented using a dictionary-passing mechanism, and we want to make sure that switching to a single generic initializer doesn't have a significant effect on how long it takes to construct these.
Note that if we do this we might have to bump the major version in order to mark the existing JSON.init(_:) methods as unavailable. The problem is that just leaving them as deprecated is still likely going to incur the type-checking penalty. But we should test.
We should consider having a
JSONCompatibleprotocol that is conformed to by things likeString,Int, etc, as a replacement for the family ofJSON.init(_:)initializers. We could then have a singleJSON.init(_:)initializer that is generic using this protocol.The goal here is to sidestep the type-checking complexity issue when using a bunch of
JSON(foo)calls in the same expression.We should also do some microbenchmarks on performance, because generics are implemented using a dictionary-passing mechanism, and we want to make sure that switching to a single generic initializer doesn't have a significant effect on how long it takes to construct these.
Note that if we do this we might have to bump the major version in order to mark the existing
JSON.init(_:)methods as unavailable. The problem is that just leaving them as deprecated is still likely going to incur the type-checking penalty. But we should test.