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