I've no idea why this is still being discussed.
This is not a proposal, there is no paper, the OP doesn't care, similarly with a thousand other equally sloppy and mindless "proposals" before. Nothing will ever come out of this.

The only motivation is "programmer lazy, so add convoluted feature to do something that was simple in less characters".

This OP's sole intention is to waste your time.

-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Simon Schröder via Std-Proposals
Sent: Friday, January 16, 2026 07:11
To: std-proposals_at_[hidden]
Cc: Simon Schröder <dr.simon.schroeder_at_gmail.com>
Subject: Re: [std-proposals] return if



> On Jan 15, 2026, at 11:46 AM, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_lists.isocpp.org> wrote:
>
> On Thu, Jan 15, 2026 at 9:54 AM Filip via Std-Proposals
> <std-proposals_at_lists.isocpp.org> 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’).
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals