> > > 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).
> >
> > QOptional does not exist yet and for very good reasons.
> >
> > QVariant is already in use, so I don't think you'd be sending a patch to u
Le mardi 11 août 2015 à 10:10 -0700, Thiago Macieira a écrit :
> On Tuesday 11 August 2015 18:45:10 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
On Tuesday 11 August 2015 19:09:22 Allan Sandfeld Jensen wrote:
> 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
> consisten
On Tuesday 11 August 2015 18:45:10 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* feat
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
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,
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. QtSq
Le vendredi 31 juillet 2015 à 09:01 -0700, Thiago Macieira a écrit :
> > wrote:
> > > In this particular case, it was reasoned that the API was inconsistent and
> > > broken. So the behaviour was changed intentionally.
> >
> > TBH, it looks like it's still inconsistent (an empty string keeps it
On Friday 31 July 2015 10:30:33 Giuseppe D'Angelo wrote:
> On Fri, Jul 31, 2015 at 10:25 AM, Thiago Macieira
>
> wrote:
> > In this particular case, it was reasoned that the API was inconsistent and
> > broken. So the behaviour was changed intentionally.
>
> TBH, it looks like it's still inconsi
On Fri, Jul 31, 2015 at 10:25 AM, Thiago Macieira
wrote:
>
> In this particular case, it was reasoned that the API was inconsistent and
> broken. So the behaviour was changed intentionally.
TBH, it looks like it's still inconsistent (an empty string keeps its
storage allocated, a string made of s
On Friday 31 July 2015 09:48:08 Oswald Buddenhagen wrote:
> 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 documen
On Friday 31 July 2015 09:53:32 André Somers wrote:
> 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?
There are corner-cases. Like using QString() to indicate no match found.
When you search for empty
* Kobus Jaroslaw [2015-07-31 07:46:07 +]:
> If you say not to differentiate empty and null states, some questions arise:
> 1) Why we have isNull and isEmpty at the same time?
> 2) Why their implementations are different?
> 3) What would be the advice on what to use in general: isNull of isEmpt
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 chang
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 empt
From: development-bounces+jaroslaw.kobus=theqtcompany@qt-project.org
on behalf
of Matthew Woehlke
Sent: 30 July 2015 18:14
To: development@qt-project.org
Subject: Re: [Development] QString behavior change
On 2015-07-30 03:38, Gerhard Scheikl wrote:
> The behavior of QString::trimmed
On 2015-07-30 03:38, Gerhard Scheikl wrote:
> 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?
Whether or not it is¹ should not be relevant;
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 m
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 54da2b
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?
By the way: the output of qDebug is not as expected:
there are additional whitespaces before tru
20 matches
Mail list logo
