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.

Sign up for GitHub

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

Jump to bottom

Move [expected] from [utilities] to [diagnostics] #6168

Open
ben-craig opened this issue Mar 11, 2023 · 6 comments
Open

Move [expected] from [utilities] to [diagnostics] #6168

ben-craig opened this issue Mar 11, 2023 · 6 comments

Comments

@ben-craig
Copy link

The [utilties] clause should be a clause of last resort, when no other clause makes sense. Additionally, the [utilties] clause has historically been one of the larger clauses.

I recommend moving [expected] from [utilities] to [diagnostics]. std::expected is a tool most frequently used for error handling, so placing it in the same clause that we use to discuss errno and terminate makes sense.

Without this change, [diagnostics] is roughly 20 pages in N4928 and [utilities] is roughly 145 pages. Moving [expected] can shift ~31 pages from [utilities] to [diagnostics].

The header table in each clause would need to be adjusted. Other than that, I didn't see any blanket wording in [utilities] that needs to be moved or duplicated into [diagnostics]. [diagnostics.general] p2 may need a minor tweak to describe std::expected.
@JohelEGP
Copy link
Contributor

See also #5315.

@jwakely
Copy link
Member

jwakely commented Mar 22, 2023

But moving expected away from optional doesn't make sense to me. I'd prefer an "object wrappers" subclause or something, for pair, tuple, variant, optional and expected.

@JohelEGP
Copy link
Contributor

What about movable-box?

@jwakely
Copy link
Member

jwakely commented Mar 22, 2023 •
edited

It's only used for exposition within the ranges clause, there's no reason to present it to users as though it's similar to optional.

@frederick-vs-ja
Copy link
Contributor

I'd prefer an "object wrappers" subclause or something, for pair, tuple, variant, optional and expected.

These components are implementations of product/sum types. Should we use "algebraic types" to describe them?

@AlisdairM
Copy link
Contributor

Do any and array belong in the algebraic type category as well?

I am planning on a paper SoonTM (might miss Tokyo 2024 though) to respecify array as a range, rather than a container, which would remove a few exceptions from our container requirements. No functional change intended.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@AlisdairM @ben-craig @jwakely @JohelEGP @frederick-vs-ja