[Development] QString behavior change

André Somers andre at familiesomers.nl
Fri Jul 31 09:53:32 CEST 2015


Op 31-7-2015 om 09:48 schreef Oswald Buddenhagen:
> On Thu, Jul 30, 2015 at 08:37:28AM -0700, Thiago Macieira wrote:
>> On Thursday 30 July 2015 11:47:16 Olivier Goffart wrote:
>>> On Thursday 30. July 2015 09:38:12 Gerhard Scheikl wrote:
>>>> Hi
>>>>
>>>> The behavior of QString::trimmed has changed from 5.3.2 to 5.5.
>>>> .trimmed() on an empty string (" ") makes it null
>>>> .trimmed() on an empty string ("") doesn't make it null
>>>>
>>>> Is this intended or a bug?
>>> This is caused by 54da2b2911ace652dbd2c8ea852c5b8c47ab09c8 in qtbase.
>>>
>>> I don't think it was intended.
>> Actually, it was. Trimming a string that doesn't need trimming returns the
>> original string. An empty string doesn't need trimming, therefore you get
>> exactly what you had.
>>
>> But PLEASE stop relying on functions that mutate strings to reliably retain or
>> fail to retain the nullness of a string. Unless the documentation for the
>> particular function makes a distinction between null and not null, assume it
>> will behave arbitrarily and will change in behaviour.
>>
> well, that recommendation is reasonable in face of the status quo, but
> i think we should (and could) do a better job at preserving nullness.
> there are only a handful of cases where the choice is arbitrary, and we
> can clearly document them.
But this surely isn't one of them? I really don't see why a non-empty 
string containing only whitespace would become a null string after 
trimming. I'd find it more logical that it would become an empty string 
instead.

If nullness can't be relied on to be retained or non-null strings can 
degrade into being a null string, what's the point of having it at all?

André




More information about the Development mailing list