Skip to content
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

[FEATURE]: Swift - Sendable JSONAny #2598

Open
gnrcampos opened this issue May 16, 2024 · 0 comments
Open

[FEATURE]: Swift - Sendable JSONAny #2598

gnrcampos opened this issue May 16, 2024 · 0 comments

Comments

@gnrcampos
Copy link

gnrcampos commented May 16, 2024

Context (Input, Language)

Output Language: Swift

Description

With the push for sendable adherence from Apple I want to suggest we change the approach to the JSONAny object that would make it adhere to the protocol (and possibly to other important protocols like Equatable and Hashable if need be).

Current Behaviour / Output

class JSONAny: Codable {
    let value: Any
    ...
}

Proposed Behaviour / Output

enum JSONAny: Codable, Sendable {
    case null
    case bool(Bool)
    case int(Int64)
    case double(Double)
    case string(String)
    case array([Self])
    case dictionary([String: Self])
    ...
}

Solution

The solution would be to change the implementation to make it an enum with associated values instead of a class with a let value Any.
For backwards compatibility purposes we can create a computed attribute that returns the old Any such as:

var value: Any {
    switch self {
    case .null:
        return JSONNull()
    case let .bool(value):
        return value
    case let .int(value):
        return value
    case let .double(value):
        return value
    case let .string(value):
        return value
    case let .array(array):
        return array.map { $0.value }
    case let .dictionary(dictionary):
        return dictionary.mapValues { $0.value }
    }
}

And an initializer that takes the value: Any as a parameter.

There are caveats such as the fact that this wouldn't work with ObjC support but we can have branching logic to keep the current implementation in this case.

I'm more than happy to create a PR for this but wanted to check with the community first to see if I'm missing anything.

Thanks in advance!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant