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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
