https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420
--- Comment #15 from Jason Merrill <jason at gcc dot gnu.org> --- (In reply to Ville Voutilainen from comment #14) > Not in general, no, it doesn't have to always give a compile-time answer. > But I believe the library intent is that when it compares compile-time > constant pointers, it should give that answer at compile-time, and it should > be a total order. Right. > What seems to be suggested by that comment is that since > it's possible to compare compile-time constant pointers and run-time values > with this function, and it can't know (definition-wise) whether the incoming > arguments are constants or not, we could just as well drop the constexpr > completely from the pointer specialization of std::less, as that will then > open the door to simply reinterpret_cast in it. None of that has been > confirmed by LWG, though. I think this is an example of the prohibition of reinterpret_cast being too broad. On the other hand, compile-time constant pointers aren't of much use. On the third hand, using std::less within an array defined in a constexpr function seems entirely reasonable and likely to come up regularly. I wonder about instead relaxing the total order requirement somewhat, to something like saying that repeated comparisons must be consistent.
