2017-03-11 23:09 GMT+01:00 Tim Song <t.canens....@gmail.com>: > On Sat, Mar 11, 2017 at 3:37 PM, Daniel Krügler > <daniel.krueg...@gmail.com> wrote: >> 2017-03-11 21:23 GMT+01:00 Tim Song <t.canens....@gmail.com>: >>> On Sat, Mar 11, 2017 at 1:32 PM, Daniel Krügler >>> <daniel.krueg...@gmail.com> wrote: >>>> This patch applies inline to all namespace scope const variables >>>> according to options A and B2 voted in during the Kona meeting, see: >>>> >>>> http://wiki.edg.com/pub/Wg21kona2017/StrawPolls/p0607r0.html >>>> >>>> During that work it has been found that std::ignore was not declared >>>> constexpr (http://cplusplus.github.io/LWG/lwg-defects.html#2773), >>>> which was fixed as well. >>> >>> Just adding constexpr to std::ignore does ~nothing. The assignment >>> operator needs to be made constexpr too; there is really no other >>> reason to use std::ignore. >> >> There is nothing in the resolution of the issue (Nor in the discussion >> that argues for the change) that says so. Yes, I considered to make >> the assignment function template constexpr, but decided against it, >> because the wording of the issue doesn't have this requirement). I'm >> also aware of a test-case which would show the difference, but again: >> This was not what the issue said. In fact I'm in the process to open a >> new library issue that should impose that additional requirement. >> >> - Daniel > > Well, technically speaking, the issue resolution doesn't even > guarantee that the use case mentioned in the issue would compile since > the standard says nothing about whether the copy constructor of > decltype(std::ignore) is constexpr, or even whether it can be copied > at all. Yes, std::ignore is underspecified, but I'm not sure I see the > point in waiting; it's a completely conforming change and IMHO the > issue's intent is clearly to make std::ignore fully usable in > constexpr functions. > > Also, the only specification we have for std::ignore's semantics is > "when an argument in t is ignore, assigning any value to the > corresponding tuple element has no effect". I think one can argue that > "causes an expression to be non-constant" is an "effect". > > Re "new library issue", we already have issue 2933.
Good point, it already exists ;-) - Daniel
