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

Jonathan Wakely jwakely@redhat.com
Thu Mar 23 17:45:00 GMT 2017

On 12/03/17 01:04 +0100, Daniel Krügler wrote:
>2017-03-11 23:14 GMT+01:00 Daniel Krügler <daniel.kruegler@gmail.com>:
>> 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 ;-)
>Revised patch attached.

The patch had a couple of typos, "onstexpr" in one place, and using
_GLIBCXX17_CONSTEXPR instead of _GLIBCXX17_INLINE in another file.

Here's what I've tested and am going to commit.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 39971 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20170323/59d1644f/attachment.bin>

More information about the Libstdc++ mailing list