WG21-P3798R1 `expected::has_error()`

[StephanTLavavej]

WG21-P3798R1 expected::has_error()

INCREASED feature-test macro:

#define __cpp_lib_expected 202606L

Note: We are not yet accepting PRs for C++29 features.

[frederick-vs-ja]

It was indicated in http://wg21.link/p3798/github that WG21-P3798R1 should be applied as a DR.

This was done in LLVM-204826 (where the author of the PR is also one author of the paper).

[StephanTLavavej]

I will formally register my annoyance that neither the paper's own text, nor the plenary motion, mentioned that this should be applied as a DR. What's going to happen next, applying papers as DRs because somebody mentioned it in a TikTok video? 🤪

That said, I have no real objection to applying this as a DR, after the WP is published and we get confirmation what the feature-test macro value should be. It takes a new member name but that's not really invasive (except for people with extremely evil macros).

[hatcat]

I will formally register my annoyance that neither the paper's own text, nor the plenary motion, mentioned that this should be applied as a DR.

That's kind of on me. LWG Chair wanted to update the poll during plenary, but I am reluctant to modify polls from the floor. It sets a bad precedent, and the LWG chair already mentioned this could be updated at the next plenary. There were already two polls modified after the deadline to accept as a DR (Accept as a Defect Report and Apply the changes in [P4101R1] and Accept as a Defect Report and Apply the changes in [P2414R12]) and I think that's going quite far enough.

Thanks for all the work you do on the MS standard library implementation. As a long term user of MS C++ products (about 35 years now) I greatly appreciate your efforts. Do keep it up!

[StephanTLavavej]

@jwakely mentioned that he doesn't want to backport expected::has_error() to C++23 mode in libstdc++, so I don't think I want to backport it for MSVC either.

[jwakely]

That's kind of on me. LWG Chair wanted to update the poll during plenary,

No, this one was not one of the polls that were supposed to be DRs, but I forgot to add that to the polls. That was LWG polls 5 and 7.

This one was not a handled as a DR by LWG at all, because the electronic poll that forwarded it to us didn't say anything about a DR, and LWG never discussed it as a DR.

The tracker issue is cplusplus/papers#2403 which shows that LEWG did poll forwarding it as a DR, but then that got lost before it reached LWG.

I'm willing to be convinced that this should be treated as a DR if that's what everybody agrees, but as things stand it was not approved as a DR and my personal opinion (not as LWG chair or libstdc++ maintainer) is that it's a new convenience feature not a fix for a defect.

[StephanTLavavej]

MSVC hasn't finalized our C++23 mode yet, so we're the least constrained. Personally, I also think this convenience feature isn't worth special-casing, and I mildly dislike the precedent that it would set.

[jwakely]

MSVC hasn't finalized our C++23 mode yet

Same for libstdc++

[hatcat]

That's kind of on me. LWG Chair wanted to update the poll during plenary,

No, this one was not one of the polls that were supposed to be DRs, but I forgot to add that to the polls. That was LWG polls 5 and 7.

Apologies chap. There was a surprising amount of business in closing plenary.

[godexsoft]

Sad to see but understandable. Sorry for the extra churn everybody.