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

[expected] Use unex as exposition-only name for all unexpected values #5403

Closed
wants to merge 1 commit into from

Conversation

frederick-vs-ja
Copy link
Contributor

Currently val is used as the exposition-only name of the data member of std::unexpected and std::bad_expected_access while the member represents an unexpected value, which is inconsistent with std::expected.

Such inconsistency has been discussed in Mick235711/wg21-papers#1.

@jwakely
Copy link
Member

jwakely commented Apr 20, 2022

But it's entirely consistent with the fact that std::unexpected<E>::value() returns val. If P2549 is accepted, this would make sense.

@jensmaurer
Copy link
Member

Let's put this change on hold until P2549 lands.

@miscco
Copy link
Contributor

miscco commented Apr 20, 2022

Actually, I made a suggestion to include it into the paper and we were unsure whether that would be a purely editorial issue or whether that would require additional review.

If not we can simply add those changes to the next revision of P2549, which would simplify things a bit

@jensmaurer
Copy link
Member

P2549 is currently pending LEWG electronic polling. I think we agree that renaming the exposition-only member is a purely editorial change, yet I would prefer to have this in the next update of the paper, before LWG starts reviewing it.

@Mick235711
Copy link
Contributor

Mick235711 commented Apr 21, 2022

yet I would prefer to have this in the next update of the paper, before LWG starts reviewing it.

I see. I would include this in R1, which if EP passes will be published in June mailing. If this does not require additional review, then it seems straightforward to me that this is a natural additional driven-by fix.

@jensmaurer
Copy link
Member

Well, LWG will review it for consistency, but LEWG won't (and doesn't need to).

@frederick-vs-ja
Copy link
Contributor Author

Abandoning this PR since it's superseded by #5692.

@frederick-vs-ja frederick-vs-ja deleted the patch-unex branch July 30, 2022 02:03
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 this pull request may close these issues.

None yet

5 participants