Date: Thu, 21 May 2026 14:37:23 +0100
On Thu, 21 May 2026 at 16:02, Andrey Semashev via Std-Proposals wrote:
> > This is useful in ternary conditional expressions, like `o.is_valid()
> > ? *o : std::unreachable<O::value_type>()`.
> How is this different from just `*o`?
std::unreachable is mainly for optimisations. In case of the specific
pattern `B ? E : std::unreachable<T>()`, it is similar to
`[[assume(B)]]; E`, but it doesn't require a separate statement. For
example, if `*o` had a check for is_value, it can be optimised out.
Another use case is something like `x < 0 ? f() : x < 5 ? g() : x < 10
? h() : std::unreachable<int>()`, which is partially documenting
(often in this case the last conditional is just omitted), but may
have some performance implications if `h()` has a check for x < 10
that the compiler fails to otherwise prove
> > This is useful in ternary conditional expressions, like `o.is_valid()
> > ? *o : std::unreachable<O::value_type>()`.
> How is this different from just `*o`?
std::unreachable is mainly for optimisations. In case of the specific
pattern `B ? E : std::unreachable<T>()`, it is similar to
`[[assume(B)]]; E`, but it doesn't require a separate statement. For
example, if `*o` had a check for is_value, it can be optimised out.
Another use case is something like `x < 0 ? f() : x < 5 ? g() : x < 10
? h() : std::unreachable<int>()`, which is partially documenting
(often in this case the last conditional is just omitted), but may
have some performance implications if `h()` has a check for x < 10
that the compiler fails to otherwise prove
Received on 2026-05-21 13:38:01
