bug#45032: 26.3; json-pretty-print of JSON with dict containing 't' as a key causes error

[Philipp Stephani <p.stephani2@gmail.com>]

Am So., 6. Dez. 2020 um 18:06 Uhr schrieb Lars Ingebrigtsen <larsi@gnus.org>:
>
> Philipp Stephani <p.stephani2@gmail.com> writes:
>
> >> >> I think it's important that native and Elisp JSON serialisation are as
> >> >> consistent as possible here;
> >> >
> >> > I don't think that's realistic: any change in behavior to either of
> >> > these functions would be a breaking change.
> >>
> >> I think we should have JSON/Elisp round trips that are 100%
> >> reproducible.  The current functions certainly aren't.
> >
> > I don't understand why that is so important. I designed the C JSON
> > functions partially because I disagree with some aspects of API design
> > and behavior of the Elisp functions, so they are pretty much
> > incompatible on purpose. Trying to make them compatible would make the
> > C functions worse.
>
> Sorry, I was unclear -- I'm not saying the old and the new functions
> should be compatible, only that there should be functions that can round
> trip via JSON->Elisp->JSON and get identical results back.
>
> Is that the case today?

You mean something like (json-serialize (json-parse-string ...))? I'd
hope that's indeed the case to the furthest extent possible. There are
cases where roundtripping is impossible (parsing ignores whitespace,
field order, and duplicate keys), but otherwise I'd hope these
functions are inverses of each other. Or is there a case where they
aren't?