Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?

On Mon, Dec 1, 2014 at 10:58 AM, Olaf van der Spek wrote:

IMO integers have a natural ordering, optionals don't.

Yes, you've said that.

The ones that we've been talking about for the entire thread in almost

...

every reply. I'm not going to repeat again.

vector? Doesn't use std:less for operator< does it? map/set?

Not vector. I was referring to set and map, whose use frequently doesn't depend on what the ordering actually is, but often only that there simply is an ordering. While on the topic though, the standard containers such as std::vector /do/ use std::less for their operator< (even though the requirements of the operation are [inconsistently] specified on the value type's operator< rather than their default ordering function). This was what I was alluding to when I said that the standard messes up requirement specification for its comparisons. To twist the knife in the standard committee's chest a bit, these types of requirement specification issues would not exist at all had we had not abandoned C++0x-style concepts (analogues of which are proving to work pretty well in Swift...). Checking of constrained templates via archetypes would catch this particular class of incorrectly constrained templates at compile-time, which is a feature that concepts-lite advocates decry as unimportant. The fact that the standard itself messes up requirement specification in this manner, despite the scrutiny it undergoes, should be reason enough to reconsider... Lots of types survive just fine without (default) ordering.

Simply surviving isn't all that one should strive for with respect to general, composite types that are defined in boost or the standard library. I think I'm still thinking about operator<

Other then map, do you have a reference for all these algorithms etc that would benefit from less>?

Any algorithm that takes a comparator and has a default (there are plenty in the standard library). This is no different from the set and map cases where you often don't care about the specific order, but rather, only that an order exists. Depending on your specific use, this can be true with respect to algorithms such as std::sort and std::binary_search, for example.

lack of a default comparator for the types in question has already led to

...

the recommendation of preferring entirely different associative datastructures over passing in an explicit comparator in this very thread (ironically, the other containers that were recommended also depend on a subjective default, only it's the default hashing function instead of the default ordering function).

How is the hash function subjective w.r.t. semantics?

Not all hash functions are created equal and there are reasons to explicitly specify one as opposed to using the default, just as there are reasons to explicitly specify an ordering function.

...

You should not be afraid to have your types be ordered when they can be ordered. Most decisions in development have a subjective aspect to them and precisely which default ordering comparator you provide is just one of those many decisions. The fact that a default is subjective (and it always is, even for arithmetic types), does not mean that a default is not useful. Why do we use less as a default for arithmetic types with respect to a set? Wouldn't greater be just as sensible?

No, IMO, though for a lot of uses it probably wouldn't matter.

Why no? Why is "less" as a default objectively better than "greater" as a default? It's simply not, we just use it by convention. The same is true for why we frequently define other operators in terms of operator<. We could just as easily have decided that operator> was the "base" operation to be used as a default and around which we built other operators. < is nothing special and not intrinsically better. I understand that you personally intuitively like < best, but you're only kidding yourself if you think that there is something deeper. -- -Matt Calabrese