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

Revisit parameter encoding when Swift supports encode to dictionary #3

Open
brendanlensink opened this issue Nov 16, 2018 · 3 comments

Comments

@brendanlensink
Copy link
Collaborator

When encoding GET parameters, we're currently encoding the params to JSON, the decoding to [String: Any]. This is far from ideal but at the time seems like the simplest way.

If Swift does add support for encoding directly to Dictionary we should jump right on that.

@brendanlensink brendanlensink changed the title Revisit Parameter Encoding When Swift Supports Encode to Dictionary Revisit parameter encoding when Swift supports encode to dictionary Oct 15, 2019
@brendanlensink brendanlensink added this to the Public Release 0.5.0 milestone Mar 12, 2020
@brendanlensink brendanlensink removed this from the Public Release 0.5.0 milestone Aug 16, 2021
@sakuraehikaru
Copy link

@brendanlensink Swift 5.6 includes https://github.com/apple/swift-evolution/blob/main/proposals/0320-codingkeyrepresentable.md

I am wondering if that's what we're looking for here?

@brendanlensink
Copy link
Collaborator Author

This is interesting, but AFAICT would only be available in iOS 15.4 and above. This is a little tricky, since I think it's unlikely any kind of backwards compatible solution will be introduced in the future.

I think we've got a feasible couple options right now:

  1. Do nothing. This hasn't really caused any problems yet, even though it's not ideal.
  2. Add support for CodingKeyRepresentable where available, leave the old solution in where it's not
  3. Drag our feet a little, eventually bump the minimum app version up and remove the old solution.

I'm sort of inclined to just go with option 1 for now, but we can probably keep this issue open for future consideration.

@sakuraehikaru
Copy link

Yeah option 3 sort of includes option 1, and the timing for option 3 is probably some time next year, when iOS 16 reaches 70% adoption rate. That could be a good time to implement CodingKeyRepresentable to be even safer, should no urgent needs arise by then.

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

No branches or pull requests

2 participants