On Thu, Sep 22, 2016 at 06:04:58AM +0200, Mathias Hasselmann wrote: > Am 22.09.2016 um 00:58 schrieb André Pönitz: > >On Wed, Sep 21, 2016 at 08:57:01AM +0200, Olivier Goffart wrote: > >>>No, it's not. It's changing undefined behavior into defined > >>>behavior. > >> > >>But in many case, we want to put something in a QVariant, and we > >>never compare this variant. Forbidding types that do not have an > >>operator== to be in a QVariant might be to strict. > > > >Forbidding types without operator== in QVariants is not needed, > >not even if one wanted to use associative container with > >QVariants as keys. > > > >[Pseudocode] > > > >bool operator(QVariant(Foo) a, QVariant(Bar) b) > >{ > > if Foo != Bar: > > return false > > if Foo has no operator==(): > > return true > > return (Foo)a == (Foo)b > >} > > > >establishes an equivalance relation by lumping all "uncomparable" > >objects into a single equivalency class. > > I rather was considering to return false.
There is not much of a choice. An equivalence relation is reflexive, i.e. at least Foo(a) == Foo(a) must be true. Lacking the ability to compare Foos, treating them all equal at least doesn't break the relation. > But indeed. Forcing all that types into a single equivalency class feels > that unnatural, that users should notice that issue much quicker, than if > we'd return false. > > Would that be sufficient to warn Qt users, or would we also have to print > a warning? I don't have an opinion on that. Andre' _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development