On Mon, Sep 15, 2025 at 2:17 PM Lorand Szollosi via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Hi,
>
> Is there a reason why we don’t have at least opt-in short-circuit for bool comarisons? I mean, I understand that currently it’s considered as int comparison and we need bacward compatibility; however, I don’t see any reason why we could not have a namespace for such operators:
>
> using std::bool_sc; // use all operators
> bool a, b; // initialize here
> return a <= b; // same as: !a || b

I don't understand the equivalence here.

If `a` and `b` are `bool`s, how is `a <= b` ever supposed to not be
true? Is it something that happens if `a` is constructed from an
unsigned integer value that's larger than `b`? And if that's the case,
how would it be equivalent to `!a || b`?

Also, it's unclear where the "short-circuit" nature of these operators
comes in. Short-circuiting, in the context of C++ boolean operators,
typically means that you don't have to evaluate both operands. If you
have two expressions X and Y that are contextually convertible to
`bool`, `X || Y` means that `Y` will only be evaluated if `X` is
false.

And note that this is "contextually convertible to `bool`". Which
means that it works on expressions that don't evaluate to a `bool`
type. So again, it's unclear how that's supposed to work.

> using std::bool_sc::operator<; // use only operator<
> bool a, b; // initialize here
> return a < b; // same as: !a && b
>
> Or even, albeit that’s a long shot:
> using std::bool_sc; // use all operators
> bool a, b; // initialize here
> return a + b; // either: a || b OR b || a
> return a * b; // either: a && b OR b && a
> The latter could be implementation-defined behavior, giving the optimizer a possibility to generate the better code.
>
> This trivially solves e.g. ‘implies’ operator (of which ther’s been already a proposal), but is also about the genericity: instead of having to use some specific operators, we could always use the best fit (and not have to worry about which argument is evaluated first when looking into the codes in most cases, which might make it easier for beginners). The con is non-deterministic behavior for the latter two (which we also have elsewhere, e.g., function arguments) and the less-than-optimal a<=b syntax for ‘implies’ (which, if problematic, we can work around locally, using something like #define for the operator, either with a unicode arrow or IMPLIES, as preferred).
>
> To go even further:
> In general, I think we currently miss some kind of ‘formula visitor’ capability of operators. Currently, if you wanted to write short-circuiting, you either have to accept lambdas explicitly (rather verbose), have expression trees (completely different types, wrappers), or resort to exceptions (which are not designed for this purpose as those are for exceptional situations; it’d be slow and difficult to debug). While I’m far from claiming to have a one-size-fits-all solution, it could be addressed I think by some kind of lazy parameter support (that, instead of taking evaluated arguments, could consider argument as callable and evaluate only when used - similarly to call-by-name). This could make most short-circuit issues user-space implementable (well, on custom types at least).
>
> Thanks,
> -lorro
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals