Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[meta.type.synop] (and other) Repetitive 'inline constexpr'? #4601

Closed
HunterKohler opened this issue May 16, 2021 · 4 comments
Closed

[meta.type.synop] (and other) Repetitive 'inline constexpr'? #4601

HunterKohler opened this issue May 16, 2021 · 4 comments
Assignees

Comments

@HunterKohler
Copy link

As can be seen in [meta.type.synop], there is constant use of inline constexpr. This is likely not limited just to this area of the text.

Example:

draft/source/utilities.tex

Lines 16155 to 16160 in 51c8df6

template<class T>
inline constexpr bool @\libglobal{is_void_v}@ = is_void<T>::value;
template<class T>
inline constexpr bool @\libglobal{is_null_pointer_v}@ = is_null_pointer<T>::value;
template<class T>
inline constexpr bool @\libglobal{is_integral_v}@ = is_integral<T>::value;

I had previously believed constexpr is implicitly inline for static data members, as specified in [dcl.constexpr]:

A function or static data member
declared with the \tcode{constexpr} or \tcode{consteval} specifier
is implicitly an inline function or variable\iref{dcl.inline}.

Is inline constexpr used for clarity of the text?

I'll assume that this is not a mistake, so please let me know the reasoning. Alternatively, if it's not useful to have inline constexpr here, I can remove it and submit a pull request.

Thanks for your time!

@HunterKohler HunterKohler changed the title [meta.type.synop] (and other) Is it repetitive 'inline constexpr'? [meta.type.synop] (and other) Repetitive 'inline constexpr'? May 16, 2021
@jwakely
Copy link
Member

jwakely commented May 16, 2021

The [dcl.constexpr] text you've quoted only refers to functions and static data members. It doesn't apply to variable templates at namespace scope. Without the inline a variable such as is_void_v<int> would have internal linkage by default, so is_void_v<int> would be a different variable in every translation unit (and potentially cause ODR violations). Making it inline means there is a single variable that is the same in every translation unit.

@timsong-cpp
Copy link
Contributor

Without the inline a variable such as is_void_v<int> would have internal linkage by default, so is_void_v<int> would be a different variable in every translation unit (and potentially cause ODR violations). Making it inline means there is a single variable that is the same in every translation unit.

We fixed that in CWG2387, but it came too late for most of the _v variable templates.

@jwakely
Copy link
Member

jwakely commented May 16, 2021

Oh good, I didn't think that had actually got fixed yet. So the inline is redundant in C++20 (but not in C++17) and could be removed now.

@frederick-vs-ja
Copy link
Contributor

Seems fixed by commit 9ac5555 (#4625 was not properly merged for some reason).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants