[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 :
>
> if(str.isNull())
> q.bind(0, QString(""));
> else
> 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.
`Allan
More information about the Development
mailing list