[Development] QOptional

[Thiago Macieira]

On Thursday 21 August 2014 16:33:12 André Somers wrote:
> Thiago Macieira schreef op 21-8-2014 16:14:
> > On Thursday 21 August 2014 11:15:01 Julien Blanc wrote:
> >> Do you mean that you would change QSqlRecord::value to return, instead
> >> of a QVariant that can be null, a QVariant holding either an optional or
> >> a non-optional object ? I don’t see any advantages in doing so. That
> >> would make sense if you could get rid of the whole QVariant stuff, but
> >> that would imho need a complete redesign of QtSql. Otherwise, it’ll just
> >> add an extra layer, not providing any usefull feature (QVariant already
> >> does the job quite well in providing the nullability feature).
> > 
> > That's exactly what I am asking for. I'd like to deprecate QVariant's
> > internal nullability concept and make it rely on carrying a QOptional for
> > a type to be null.
> > 
> > If we don't do that, then QVariant: of a QOptional<QString> could be:
> >   1) a null QVariant
> >   2) a non-null QVariant containing a null (disengaged) QOptional
> >   3) a non-null QVariant containing a non-null (engaged) null QString
> >   4) a non-null QVariant containing a non-null (engaged) non-null QString
> > 
> > That's just non-sense and confusing to me. I'd like to collapse 1-3 as
> > much as possible.
> 
> I assume you also want to remove the nullability of QString then?
> In both cases, you're going to break *a lot* of code.

I don't think that's wise.

But I'd like QOptional<QString> o = QString() result in a null (disengaged) 
QOptional too.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center