[Development] QString behavior change
Allan Sandfeld Jensen
kde at carewolf.com
Tue Aug 11 19:09:22 CEST 2015
On Tuesday 11 August 2015, Julien Blanc wrote:
> Le mardi 11 août 2015 à 08:46 -0700, Thiago Macieira a écrit :
> > On Tuesday 11 August 2015 10:38:27 Julien Blanc wrote:
> > > That point is certainly valid, but i would like to raise the point that
> > > string nullness is a *required* feature for QtSQL (a null QString is
> > > converted to a NULL SQL, whereas a non-null empty QString is converted
> > That's a misfeature. QtSql should have been using something like
> > QOptional<QString> for a nullable string. In addition, it usually uses
> > QVariant, which has its own null setting -- it allows for a null int,
> > different from a value of zero.
> What are the chances that such a change can be accepted ? (i mean, i can
> submit such a patch, but that would mean breaking a *lot* of code).
> > > So, could you consider returning StringType("") instead ? (unless i’m
> > > wrong, null strings should be handled by the first condition).
> > No.
> By no, do you mean that i am wrong (ie, a null QString passing via
> trimmed_helper would fail the begin == str.cbegin() && end == str.cend()
> test, for a reason i don’t understand, nor does my compiler), or that
> you have a good reason for not returning StringType("") ? In the latter
> case, i would be very glad if you explain it.
> > If you want to pass a null QString to QtSql, you can. If you want to
> > check whether a string you got from QtSql is null, you can.
> Please consider the following case :
> q.bind(0, QString(""));
> q.bind(0, str.trimmed());
> That code looks perfectly valid, but is in fact broken by a subtle,
> counter-intuitive implementation detail.
> > That has nothing to do with trimmed(). Other API doesn't guarantee to
> > keep null either when mutating strings, so I don't see why we should
> > here. If the API doesn't specifically deal with null QStrings, expect
> > that it will randomly change between null and not null.
> If nullness of QString is so much broken, then please consider removing
> it at all (Qt6 ?). I will thank you for that. But until that’s done, is
> it possible to not add more brokenness to it ?
I would second that. We can argue that the null vs empty is a misfeature we
like to discourage because it is likely to break in some corner-cases, but
until we get rid of it (Qt6), there is no reason to not try to be consistent,
and deal properly with the differences when bugs are reported.
More information about the Development