[Development] [RFO QTBUG-84739] QJsonValue::fromVariant containing QByteArray

[Thiago Macieira]

On Wednesday, 1 July 2020 15:29:33 PDT Tor Arne Vestbø wrote:
> Hi,
> 
> I can sympathize with the reporter that this is a quite serious regression
> from the user’s point of view, but I also see your point about the new
> behavior not being lossy.
 
> Would it be an alternative to add an argument to QJsonValue::fromVariant
> e.g. that defaults to the old, unsurprising behavior, but allows opting in
> to the safer approach?

That can't be done in 5.15, since we can't add a new function so it can take 
an argument. We may relax the rule about forwards-and-backwards compatibility 
later for 5.15 like we did for 4.8, but that hasn't happened yet.

Either way, it would need to be the inverse: opt in to the new behaviour. If 
we're going to require users to adapt anyway, then we can ask them to fix 
their QVariants in the first place.

> I assume people who put “true” binary data into their QByteArrays and
> convert that to JSON would have pre-base64-encoded it manually already, to
> avoid the data loss, so this is a surprising change for those that just use
> it as a poor man’s string. 

Agreed, anyone who needed to send binaries in the past would have encoded 
somehow (base16, base64 or base64url), but they might have also already moved 
it to QString because that's what's documented. If they haven't -- and 
QByteArray::toBase64 returns QByteArray -- then we get double encoding, which 
is wore.

In a green field scenario, the new behaviour is quite useful. You don't need 
to pre-encode, the converter will do it for you.
 
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products