[Development] QOptional

[Thiago Macieira]

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.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center