Support Symbols for Hash keys

[mperham]

json/add/core does not support Symbols for Hash keys today. This is a major issue for downstream systems like Sidekiq which rely on JSON for serialization because we can't transparently serialize the full range of method arguments like keywords.

I'd like to propose a way to support Symbol'd keys by "smuggling" the type in the String itself:

{
  :mike => 123
}

{
  "_s:mike": 123
}

This would allow Sidekiq users to use keyword arguments in their jobs without any issues. What do you think?

See also https://github.com/sidekiq/sidekiq/pull/6209

[mperham]

And I would be perfectly ok with this being opt-in: JSON.generate(..., type_smuggling: true)

[jhawthorn]

I don't think the JSON gem should support this. It sounds like a reasonable thing to do for Sidekiq but is too specific for a general JSON gem (hard to draw a line for which specific classes/types this should/shouldn't support) and isn't part of the standard. The good news is that this seems best implemented in pure-Ruby wherever it lives!

One problem this has is that if Ruby's {:mike => 123} is represented as the JSON "_s:mike" how do you represent the Ruby {"_s:john" => 456}? Presumably with a different prefix but once that is done "standard" JSON isn't 1:1 loadable as "smuggled" JSON and you might as well have a heavier/specific format.

This would allow Sidekiq users to use keyword arguments in their jobs without any issues.

Keyword arguments probably also requires additional work/hacks/annotations, since in Ruby 3.0+ they'll need to be separated from your positional arguments (in which case you could just know the keys are Symbols) OR you'll have to round-trip the ruby2_keywords value of the hash, which is what ActiveJob does.

[byroot]

I agree with John, json/add/ have been the source of many RCEs etc, and I'm planning to deprecate and extract it in the next major.

So I'd rather not add more of this sort of capabilities.