-
Notifications
You must be signed in to change notification settings - Fork 189
Bare minimum [U]Int128 support for JSON encode/decode #767
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bare minimum [U]Int128 support for JSON encode/decode #767
Conversation
This doesn't yet tackle _slowpath_unwrapFixedWidthInteger, but at least allows us to round-trip [U]Int128 with our own encoder and decoder
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense to add BPlist support at the same time?
This piece is fine. BPlist might be a separable piece, considering its complication, if you prefer to split them up. |
@@ -1128,6 +1128,11 @@ extension JSONDecoderImpl : SingleValueDecodingContainer { | |||
func decode(_: Int64.Type) throws -> Int64 { | |||
try decodeFixedWidthInteger() | |||
} | |||
|
|||
@available(macOS 15.0, iOS 18.0, tvOS 18.0, watchOS 11.0, visionOS 2.0, *) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In other places in the project, we use availability like FoundationPreview 0.4
(which "back deploys" to macOS 13.3) or FoundationPredicateRegex 0.4
(which has macOS 15 aligned availability). Is it worth using/creating a FoundationPreview-based availability specifier for this, or should we just explicitly write out the availability here like it is now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another benefit of using the FoundationPreview macro is that it is defined to be the min deployment target when building the package, making it possible to test this implementation on older OSes instead of requiring a host OS of macOS 15.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think in this case we likely do need a host OS of macOS 15 since I don't think UInt128
will be present on macOS <15, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, that's why you mentioned the Predicate-specific availability here. I was hoping those wouldn't proliferate too much, but maybe we don't have a choice...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, we need to match the availability of Int128, so I think it's fine to write these out explicitly. There's not too much value in making these into a macro, since they are not going to change.
@swift-ci test |
macOS failure is because the macOS tests run on a 13.x host, where Int128 doesn't exist. They're marked |
Also added some slow-path testing for [U]Int128, to ensure that we throw an error as expected in these cases instead of returning an incorrect value.
@swift-ci test |
1 similar comment
@swift-ci test |
* Bare minimum [U]Int128 support for JSON encode/decode This doesn't yet tackle _slowpath_unwrapFixedWidthInteger, but at least allows us to round-trip [U]Int128 with our own encoder and decoder * Switch to if #available check for Int128 tests Also added some slow-path testing for [U]Int128, to ensure that we throw an error as expected in these cases instead of returning an incorrect value.
This doesn't yet tackle _slowpath_unwrapFixedWidthInteger, but at least allows us to round-trip [U]Int128 with our own encoder and decoder.