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

[Edward Welbourne]

Am 01.07.2020 um 23:21 schrieb Thiago Macieira:
>>> Re: https://bugreports.qt.io/browse/QTBUG-84739
>>> Summary: Qt 5.15 has an unintentional change in behaviour that has
>>> broken existing applications. We need to decide whether to:
>>>   a) leave as-is
>>>   b) revert permanently
>>>   c) revert for 5.15.x but keep the new behaviour in 6.x

Mathias Hasselmann (2 July 2020 11:12)
> How about:
>
> d) Follow the C++ trend of banning implicit conversions and make the
> function fail for all input that is as underspecified as a QByteArray.

That may be a plausible option for Qt 6, but is too big a behaviour
change for 5.15.1.  So how about: revert on 5.15 and think about how
radically we want to change the behaviour for QT 6 ?
We have a month ...

Presumably code that does
  QString encoded = QString::fromUtf8(data.toBase64());
and sends the encoded string (legitimately encoded as CBOR String)
can have it received by code that does
  QByteArray decoded = QByteArray::fromBase64(received.toUtf8());
to reliably get decoded back equal to the originally supplied data.
Perhaps that would be worth documenting.

Thiago Macieira (2 July 2020 02:48)
>> 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.

Will the converter coming the other way post-decode ?
If I'm sending and receiving data, I expect the receive side to "mirror"
the send side; so if the send side doesn't need to Base-64 the data,
because it's done internally, the receive side shouldn't need to either.
If it does, the asymmetry will confuse users of this behaviour.
Which may be an argument for, as Mathias suggests, dropping it.

	Eddy.