Subject: Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-11-26 18:49:26
On 27/11/2014 11:03, Gottlob Frege wrote:
> I'd support dropping op< and only having ==, !=, and std::order/std::less.
TBH, other than the "existing code" issue I'm not sure I like the idea
of std::less working but op< not -- and in particular if you don't agree
with the idea that "none is less than any other value" then I don't know
why you'd agree with the idea that it should sort that way in a map,
which is what you appear to be suggesting.
Perhaps std::less should not support it either, but std::hash should,
and if you want to use optional keys then you have to use
But why do you want to have optional keys anyway? When does it make
sense to have a single value attached to an empty key? It's rare for a
dictionary type to permit null keys in any language.
OTOH, I don't have any personal problems with
op<(optional<T>,optional<T>) existing and with its current behaviour,
other than the apparent disagreement about where "none" should sort (and
I don't have any issues with the library author having defined this as
"less", though apparently others do).
I'm less convinced of the merit of op<(optional<T>,T), as the reality is
that in *real life code* this is most likely to be a coding error rather
than something intentional. Perhaps this is just a failure of
imagination, but other than toy examples I cannot imagine a case where
someone would use this intentionally. I'm not sure I'd go as far as
advocating that they be explicitly removed or poisoned, but I suspect
that this would improve overall code quality without unduly burdening
people who do want to make this comparison.
I am absolutely convinced of the merit of implicit optional<T>(T)
construction and assignment, and op== working for both, and would regard
it as a bug if these were removed.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk