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