[RFC] Should _GLIBCXX_CONSTEXPR, _GLIBCXX14_CONSTEXPR etc. expand to 'inline' ?

[Jonathan Wakely]

On 27/09/19 15:32 +0300, Antony Polukhin wrote:
>On Fri, Sep 27, 2019, 15:02 Jonathan Wakely <jwakely@redhat.com> wrote:
>
>> Currently we have lots of code that has:
>>
>> inline _GLIBCXX14_CONSTEXPR void
>> foo()
>>
>> When the macro expands to 'constexpr' the 'inline' is redundant,
>> because constexpr implies inline.
>>
>> For older standards we could make it expand to 'inline' instead of
>> 'constexpr' and then we don't need the sometimes-redundant 'inline'
>> there.
>>
>
>I'm in favour of this change.
>
>This would be a change if we have some functions that are *not*
>> declared 'inline' for older standards, but become inline when they're
>> constexpr functions. I'm not aware of any cases like that.
>>
>
>It may also add inline to template functions that do not have explicit
>inline on them otherwise. Does the GCCs optimizer uses an explicit inline
>as a hint for function inlining

Yes, it does, although I think that's a mistake.

> and should we care about such differences?

I was assuming that most functions that are suitable for 'constexpr'
will be small and simple enough that they should already be marked
'inline'.

However, for C++20 that's definitely not true, because nearly every
function is inline! There are certainly lots of function templates in
<algorithm> which are not currently inline.

We could make _GLIBCXX_CONSTEXPR, _GLIBCXX14_CONSTEXPR and
_GLIBCXX17_CONSTEXPR expand to inline, but not _GLIBCXX20_CONSTEXPR,
but that somewhat weakens the argument for making the change.