Skip to content

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

Merged
merged 2 commits into from
Jul 26, 2024

Conversation

stephentyrone
Copy link
Contributor

This doesn't yet tackle _slowpath_unwrapFixedWidthInteger, but at least allows us to round-trip [U]Int128 with our own encoder and decoder.

This doesn't yet tackle _slowpath_unwrapFixedWidthInteger, but at least allows us to round-trip [U]Int128 with our own encoder and decoder
@stephentyrone stephentyrone requested a review from kperryua July 25, 2024 15:50
Copy link
Contributor

@parkera parkera left a 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?

@kperryua
Copy link
Contributor

This piece is fine. BPlist might be a separable piece, considering its complication, if you prefer to split them up.
However, XMLPlistDecoder should be pretty straightforward to include here since it ultimately uses the same _parseHexIntegerDigits() and _parseIntegerDigits() that JSONDecoder uses.

@@ -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, *)
Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Contributor

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?

Copy link
Contributor

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...

Copy link
Contributor Author

@stephentyrone stephentyrone Jul 25, 2024

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.

@parkera
Copy link
Contributor

parkera commented Jul 25, 2024

@swift-ci test

@stephentyrone
Copy link
Contributor Author

stephentyrone commented Jul 26, 2024

macOS failure is because the macOS tests run on a 13.x host, where Int128 doesn't exist. They're marked @available but the test infra tries to run them anyway. Switching this to an if #available check instead.

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.
@stephentyrone
Copy link
Contributor Author

@swift-ci test

1 similar comment
@stephentyrone
Copy link
Contributor Author

@swift-ci test

@stephentyrone stephentyrone merged commit ed7b97b into swiftlang:main Jul 26, 2024
3 checks passed
@stephentyrone stephentyrone deleted the int128-support-in-json branch July 26, 2024 20:55
glessard pushed a commit to glessard/swift-foundation that referenced this pull request Jul 29, 2024
* 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants