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

[ben-craig]

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]

See also #5315.

[jwakely]

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]

What about movable-box?

[jwakely]

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]

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]

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.