[Development] QString behavior change

[Allan Sandfeld Jensen]

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