[libcxx-commits] [PATCH] D98983: [libcxx] adds concepts `std::totally_ordered` and `std::totally_ordered_with`
Arthur O'Dwyer via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Tue Mar 23 13:23:33 PDT 2021
Quuxplusone added inline comments.
Comment at: libcxx/test/std/concepts/comparison/concepts.totallyordered/totally_ordered.compile.pass.cpp:45
> Mordante wrote:
> > This feels wrong, when a double has a NaN value there's no total order. I wonder whether this is a bug in the Standard.
> It's a common misconception that floating-point numbers can't model `totally_ordered` because of NaN.
> From [[ http://eel.is/c++draft/cmp.concept#1.1 | cmp.concept ]]:
> > `t < u`, `t <= u`, `t > u`, `t >= u`, `u < t`, `u <= t`, `u > t`, and `u >= t` have the same domain.
> NaN is outside this domain, which I believe is documented by floating-point specifications.
> Andrew Sutton sums this up in his [[ https://youtu.be/ZeU6OPaGxwM?t=1980 | CppCon 2019 talk ]]. Specifically:
> > Concepts do not hide preconditions. Syntactic operations are not total operations. Floating point types are totally ordered even though NaN exists.... because there's a precondition on the algorithms that use the operation.... Random-access iterators are totally ordered, even though the relation is really sparse.
+1 @cjdb. A Concept like `totally_ordered` is ultimately just a way of organizing source code, like saying "does it make sense to have a `std::set` of these things." You can make a `std::set<double>` just fine. It does misbehave badly if you try to put NaN into it; but, you just have to remember not to do that.
Andrew Sutton wrote:
> > Random-access iterators are totally ordered, even though the relation is really sparse
Now //that's// stretching the philosophy to the breaking point, I think ;) but sure, it can make sense to have a `std::set<std::deque<T>::iterator>`, as long as you're careful to put into it only iterators from a single container and never let them become invalidated.
Or come at it from the other side: Concepts describe the requirements of algorithms, i.e. what cases the algorithm needs to worry about. If the places-where-the-natural-ordering-fails also happen to be places-where-our-algorithms-don't-care-about-the-result (maybe because they're UB), then the concept remains useful in practice.
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
More information about the libcxx-commits