Repository navigation
Move [expected] from [utilities] to [diagnostics] #6168
Description
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.
Activity
JohelEGP commentedon Mar 11, 2023
See also #5315.
jwakely commentedon Mar 22, 2023
But moving
expectedaway fromoptionaldoesn't make sense to me. I'd prefer an "object wrappers" subclause or something, for pair, tuple, variant, optional and expected.JohelEGP commentedon Mar 22, 2023
What about
movable-box?jwakely commentedon Mar 22, 2023
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 commentedon Apr 3, 2023
These components are implementations of product/sum types. Should we use "algebraic types" to describe them?
AlisdairM commentedon Nov 9, 2023
Do
anyandarraybelong in the algebraic type category as well?I am planning on a paper SoonTM (might miss Tokyo 2024 though) to respecify
arrayas a range, rather than a container, which would remove a few exceptions from our container requirements. No functional change intended.