Re: [Patch] Inline Variables for the Standard Library (p0607r0)

[Tim Song <t dot canens dot cpp at gmail dot com>]

On Sat, Mar 11, 2017 at 3:37 PM, Daniel Krügler
<daniel.kruegler@gmail.com> wrote:
> 2017-03-11 21:23 GMT+01:00 Tim Song <t.canens.cpp@gmail.com>:
>> On Sat, Mar 11, 2017 at 1:32 PM, Daniel Krügler
>> <daniel.kruegler@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.

Tim