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

STL: Consider consistently rephrasing Standard mode diagnostics #250

Closed
StephanTLavavej opened this issue Nov 2, 2019 · 3 comments · Fixed by #252
Closed

STL: Consider consistently rephrasing Standard mode diagnostics #250

StephanTLavavej opened this issue Nov 2, 2019 · 3 comments · Fixed by #252
Labels
enhancement Something can be improved fixed Something works now, yay!

Comments

@StephanTLavavej
Copy link
Member

When a header for a newer C++ Standard is compiled with an older Standard mode, it emits a diagnostic. Our phrasing varies; some talk about the contents of the header:

#pragma message("The contents of <charconv> are only available with C++17 or later.")

Others talk about the main class or class template defined by that header:

STL/stl/inc/any

Line 445 in 28ec9a3

#pragma message("class any is only available with C++17 or later.")

#pragma message("class template variant is only available with C++17 or later.")

Some don't bother to say "class" (and ignore the distinction between the basic_string_view class template and the string_view typedef):

#pragma message("string_view is only available with C++17 or later.")

And some have custom phrasing:

#pragma message("Parallel algorithms are only available with C++17 or later.")

Should we be consistent about this phrasing?

@StephanTLavavej StephanTLavavej added the enhancement Something can be improved label Nov 2, 2019
@StephanTLavavej
Copy link
Member Author

My preference: "The contents of <meow> are only available with C++MEOW or later." This is currently used by <charconv>, <compare>, <concepts>, <filesystem>, <memory_resource>, and <ranges>.

@CaseyCarter
Copy link
Member

CaseyCarter commented Nov 2, 2019

Didn't @BillyONeal suggest that we should invert the conditionals that guard these "downlevel" diagnostics so the #pragma is nearer the top of the header file? (Admittedly these are separable issues, but the level of "creep" from combining them seems small to me.)

@SuperWig
Copy link
Contributor

SuperWig commented Nov 2, 2019

There's code inconsistencies too.

C++20 vs _HAS_CXX20 / ! vs not

#else // ^^^ C++20 / not C++20 vvv

#else // ^^^ Concepts support / no Concepts vvv

#else // ^^^ <concepts> supported / <concepts> not supported vvv

Double sided arrows
#else // ^^^ _HAS_CXX17 ^^^ / vvv !_HAS_CXX17 vvv

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Something can be improved fixed Something works now, yay!
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants