[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