Allowing single quotes for strings in literal JSON content

[hattesen]

Currently, you can construct a simple json object from a literal JSON string like ...

json j = "{\"happy\": \"day\", \"pi\": 3.141}"_json;

... but it isn't pretty with all the embedded backslashes.

What about allowing embedded apostrophe characters (', U+0027) in a literal JSON string as a stand-in for quotation marks (", U+0022), making this source functionally equivalent to the one above ...

json j = "{'happy': 'day, 'pi': 3.141}"_jsons; 

... a lot easier to type AND to read¹

1. The _jsons user-defined literal suffix would work just like _json, except treating every occurrence of an apostrophe (') as a stand-in for a quotation mark (").
2. I realize that the literal JSON string in the source code is not well-formed JSON, but ...
   • neither is the literal JSON string in the first example (due to the embedded backslashes)
   • it only exists in the source code, and will only ever leak outside the source code if done intentionally
3. Apostrophy characters (') embedded in JSON content
   • This proposal would fail to handle JSON literals with JSON content having an embedded apostrophe character, e.g. ['Do', 'Don't'], but I bet that it would cope with 99% of literal JSON strings in the wild, and you can always fall back to using _json as before
   • I don't propose any special parsing tricks to allow embedded apostrophy characters like the one above, as it would just add a layer of complexity on top of a non-standard syntax, although ...
     • ... you COULD say, that a single quote appearing between two word characters (regex /[a-zA-Z0-9_]'[a-zA-Z0-9_])/) should be treated as a literal (embedded) apostrophy, which would handle the vast majority cases, but not something like ['Charles' crown']
     • ... or only perform (' ➡️ ") substitutions in places where a " would be permitted in well formed JSON, but that would require a LOT more work implementing and testing
4. It could be implemented very easily, having virtually zero risk of causing any side effects (bugs) elsewhere
5. It would only contribute a miniscule amount of code to the project and its documentation and thus the cognitive load
6. It would not pose any backward compatibility issues
7. It would not, in any way, conflict with any current C++ or json library rules, conventions or best practices

I would like to hear arguments why this would NOT be a good idea to implement

Footnotes

1. Note the _jsons (rather than _json) user-defined literal suffix ↩

[gregmarr]

Just use a raw string literal https://en.cppreference.com/w/cpp/language/string_literal:

nlohmann::json j = R"({"happy": "day", "pi": 3.141})"_json;