This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch] Inline Variables for the Standard Library (p0607r0)
2017-03-11 23:09 GMT+01:00 Tim Song <t.canens.cpp@gmail.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.
Good point, it already exists ;-)
- Daniel