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

<mutex> : enable constexpr default constructor by, err, default #4338

Closed
CaseyCarter opened this issue Jan 23, 2024 · 1 comment · Fixed by #4339
Closed

<mutex> : enable constexpr default constructor by, err, default #4338

CaseyCarter opened this issue Jan 23, 2024 · 1 comment · Fixed by #4339
Labels
enhancement Something can be improved fixed Something works now, yay!

Comments

@CaseyCarter
Copy link
Member

Some background:

#3824 fixed a decade-old bug by making the default constructor of std::mutex be constexpr. There was much rejoicing. There was also some wailing and gnashing of teeth from folks in Microsoft who were using current headers and old libraries - an unsupported scenario - who had to fix their broken builds/processes/pipelines. We had anticipated such problems, and added an opt-out macro specifically so folks could transition on their own timelines.

At the 11th hour before release, we realized that MSVC supports the UWP framework libraries from the Windows store with the live headers (:boggle:). While we were happy to stick to our guns and force misbehaving internals to fix their stuff in order to ship a fix for a ten-year-old bug, breaking well-behaved users was a non-starter. #4000 made the feature opt-in instead of opt-out to avoid breaking folks in 17.8 until we could get the UWP framework libraries updated.

The UWP library update process is incredibly slow but should be complete in time for us to re-enable the constexpr constructor by default (flipping back from opt-in to opt-out) in the 17.10 timeframe. This issue is a reminder to do so.

@CaseyCarter CaseyCarter added blocked Something is preventing work on this enhancement Something can be improved and removed blocked Something is preventing work on this labels Jan 23, 2024
@CaseyCarter
Copy link
Member Author

The necessary update completed a few hours ago, this change is unblocked. I'm preparing a PR.

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.

2 participants