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

<variant>: Should we treat P0608R3 as a DR against C++17? #4412

Closed
frederick-vs-ja opened this issue Feb 19, 2024 · 6 comments
Closed

<variant>: Should we treat P0608R3 as a DR against C++17? #4412

frederick-vs-ja opened this issue Feb 19, 2024 · 6 comments
Labels
question Further information is requested resolved Successfully resolved without a commit

Comments

@frederick-vs-ja
Copy link
Contributor

frederick-vs-ja commented Feb 19, 2024

WG21-P0608R3 was intentedly not treated as DR by MSVC STL (#1629 (comment)).

However, the author of P0608R3 (@zhihaoy) applied those changes to libc++ in C++17 mode (LLVM-D44865), and so did libstdc++ (gcc-mirror/gcc@d069df0). So it's arguably that P0608R3 should be treated as DR even though it's not so treated officially.

There's at least one user even thinking MSVC STL is buggy (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113007#c7).

Edit: And DevCom-10606398.

@frederick-vs-ja frederick-vs-ja added the question Further information is requested label Feb 19, 2024
@jwakely
Copy link

jwakely commented Feb 19, 2024

See also #2171 (comment)

@toughengineer
Copy link

toughengineer commented Feb 19, 2024

There's at least one user even thinking MSVC STL is buggy (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113007#c7).

That user is me.
Just to clarify, I wrote in that bug conversation:

Now it's time to file a bug in MSVC's standard library.

but before actually filing a bug I learned roughly from the issue #2171 mentioned by @jwakely above or from the issue #1629 mentioned by @frederick-vs-ja in the initial comment that MSVC developers decided to leave the initial implementation in C++17 mode for backwards compatibility, at least this is my understanding, so I never filed an issue because I though it is redundant.

@StephanTLavavej
Copy link
Member

We talked about this at the weekly maintainer meeting, and we just don't have the maintainer capacity needed to deal with cleaning up usage in the compiler and potentially Windows and elsewhere, if we changed our decision here to align with libstdc++ and libc++. Our behavior is conforming according to C++17 and we need to spend our energy elsewhere.

@StephanTLavavej StephanTLavavej added the resolved Successfully resolved without a commit label Feb 21, 2024
@StephanTLavavej
Copy link
Member

Revisiting this - it turned out to be necessary to fully update our libcxx-derived variant tests. I'll have a PR in the near-ish future.

@toughengineer
Copy link

If you decide to change the behavior in C++17 mode to include P0608, please consider updating macros

STL/stl/inc/yvals_core.h

Lines 881 to 883 in e36ee6c

#define _CPPLIB_VER 650
#define _MSVC_STL_VERSION 143
#define _MSVC_STL_UPDATE 202405L

_CPPLIB_VER (currently 650, as in ?)
_MSVC_STL_VERSION (currently 143, as in runtime version 14.3/v143?)
_MSVC_STL_UPDATE (I guess only this one will be updated)
so that user code can detect that starting with that version of the standard library it does not need a workaround for unimplemented P0608.

@frederick-vs-ja
Copy link
Contributor Author

frederick-vs-ja commented May 31, 2024

_MSVC_STL_UPDATE (I guess only this one will be updated)

Yeah, this one is updated every month. We regularly open a good-first-issue for updating it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested resolved Successfully resolved without a commit
Projects
None yet
Development

No branches or pull requests

4 participants