> On Jan 15, 2026, at 11:46 AM, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Thu, Jan 15, 2026 at 9:54 AM Filip via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>>
>> return if appears to be basically an assert that does not stop your program from running.
>>
>> Maybe it is better to just use something similar to assert?
>>
>> ```
>> 1. soft_assert(foo());
>> 2. soft_assert(foo(), default_return_value);
>> ```
>
>
> No that's not the intention.
>
> Imagine you have a function that retrieves the UUID for a given
> signatory on a bank account, and the bank operates in 3 different
> countries:
>
> __uint128_t GetSignatoryID( chrono::time_point date_of_birth,
> string_view primary_surname_on_birthcert, string_view
> primary_forename_on_birthcert )
> {
> return if manager.GetRegion("Sweden" ).FindRecord(
> date_of_birth, primary_surname_on_birthcert,
> primary_forename_on_birthcert );
> return if manager.GetRegion("Germany").FindRecord(
> date_of_birth, primary_surname_on_birthcert,
> primary_forename_on_birthcert );
> return if manager.GetRegion("Japan" ).FindRecord(
> date_of_birth, primary_surname_on_birthcert,
> primary_forename_on_birthcert );
>
> return GenerateNewID( date_of_birth,
> primary_surname_on_birthcert, primary_forename_on_birthcert );
> }
This example makes it clear what the main problem with your example is: It is bad API design because you are mixing the error state with the data. We do have std::expected now (kind of a result type). This separates the error from the actual return value. In new projects I have started to use std::expected + std::error_code + std::error_condition. And I believe that this should be the way forward (even though it is quite cumbersome to write). The main problem with good error handling is not to return a value early, but to return the error if one was returned from calling a function. In order for ‘return if’ to work with std::expected it would have to look even differently because it would have to call operator* (dereference operator) to return the result. And in the case of ‘return ! if’ it would have to rewrap the error code and return that (if would not just negate the condition and still return the value). It looks like your proposed feature does not work well with std::expected (which would further add to the confusion). Or we would need a customization point what to return on success or failure of the condition:
return if result; -> if(result) return *result;
return ! if result; -> if(!result) return std::unexpected{result.error()};
There is no precedent for customizing keywords (and even different customizations for ‘if’ and ‘! if’).