GNU bug report logs - #70007
[PATCH] native JSON encoder

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Mattias Engdegård <mattias.engdegard <at> gmail.com>, Andrea Corallo <acorallo <at> gnu.org>, casouri <at> gmail.com, Stefan Kangas <stefankangas <at> gmail.com>, 70007 <at> debbugs.gnu.org
Subject: bug#70007: [PATCH] native JSON encoder
Date: Sun, 25 Aug 2024 13:55:53 -0400

>> > Since this could potentially (albeit unlikely) break someone's code,
>> > I'm okay with making this change, but with a twist: let's have a
>> > variable which could be let-bound around the call to json-serialize,
>> > to make the result a multibyte string instead of the default unibyte.
>> > This is so if someone comes back crying that we broke his/her code,
>> > they could have an easy fire escape.
>> Sure, but it's a bit annoying to saddle us with some baggage that we never
>> expect to be actually used.
>> And for that matter, it's no easier to bind a variable around the call
>> than putting a call to `decode-coding-string` around it, is it? We could
>> describe that in NEWS.

The variable solution has one advantage: users can (setq ... t) in their
`.emacs` to keep old code working, tho potentially at the cost of
breaking new code.

Another option is to introduce a new name (that outputs a unicode
string) and obsolete the old one.  🙂

But just making a breaking change is not that bad: ELisp has evolved to
be pretty good at making code magically work for both encoded and
decoded strings.

>> The null option is to do nothing and stick to what we have now.
>> It's not a terrible choice either.

Returning an encoded strings is something we do want to avoid in the
long run, so we might as well bite the bullet now.

> Let's see what others think about this.  Stefan, Stefan, and Andrea:
> any opinions wrt what, if anything, we should do about this on the
> emacs-30 branch?

I vote for breaking compatibility.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.