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
> >>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.
> >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
> 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.
Development mailing list