[llvm-bugs] [Bug 31820] New: operator<(std::nullptr_t, std::nullptr_t) should be allowed

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Jan 31 09:26:39 PST 2017


https://llvm.org/bugs/show_bug.cgi?id=31820

            Bug ID: 31820
           Summary: operator<(std::nullptr_t, std::nullptr_t) should be
                    allowed
           Product: libc++
           Version: 4.0
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jared.grubb at gmail.com
                CC: llvm-bugs at lists.llvm.org, mclow.lists at gmail.com
    Classification: Unclassified

Recently, Richard Smith made a change to address two DR's:
Commit:
https://github.com/llvm-mirror/clang/commit/c1d70e9b5c41fdb4c565638715a03a83503b7fae

The gist of the patch was to disallow "nullptr < p", which I agree makes sense.
However, when p is actually std::nullptr_t, then it is now a compiler error,
and I don't agree with this.

std::nullptr_t should be a regular type in all the Stepanov ways unless there's
a good reason to disallow it. I don't see why the std::nullptr_t should not be
totally ordered (in the trivial way).

This is not a theoretical problem because it did break a line of code in a JSON
library that I use. It was easy to work around but I dont think the code should
be disallowed:
   https://github.com/dropbox/json11/blob/master/json11.cpp#L166
Here, the code ends up trying to do "this->m_value < other.m_value" where both
members are std::nullptr_t (in the implementation for Value<tag,
std::nullptr_t>).

I would like to ask that libc++ put back the overload to make "nullptr <
nullptr" allowed as an extension. GCC and MSVC both allow this, and clang did
until the latest version.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170131/39d41583/attachment-0001.html>


More information about the llvm-bugs mailing list