Date: Thu, 5 Feb 2026 11:46:06 +0000
On Mon, Jan 12, 2026 at 12:00 AM Frederick Virchanza Gotham wrote:
>
> So to break it down logically, here's what's going on:
>
> auto const retval = SomeFunction();
> if ( static_cast<bool>(retval) ) return retval;
>
> Now personally I think that this would be much more succinctly
> expressed as follows:
>
> return if SomeFunction();
I have written "return if" into the GNU g++ compiler. There are two
possible syntaxes:
return if expr;
return @ if expr;
In the second syntax, the @ symbol is any one of the unary operators:
+ - ! ~ * &
The second form with the unary operator was easier to code into the
compiler, as I didn't have to worry about whether or not the return
type was immovable-and-uncopiable, because if "operator@" returns a
PRvalue then it just gets returned as a PRvalue (because C++23
guarantees RVO).
The first form without the unary operator took a little more work. I
had to consider if the return value went in registers or in memory
(because normally on x86-64, it goes in RAX and RDX). When dealing
with a function that returns an immovable-and-uncopiable type by
value, the return value will never go in registers -- it will go in a
"return slot" whose address is typically passed in the first register
(i.e. RDI on x86-64 System V), so I had to manually manipulate the
return slot. Thankfully I didn't have to manually manipulate the RDI
register as the GNU g++ compiler allowed me to work at a higher level
than that, so I think my patched compiler should work fine if built
for aarch64 or x86_32 or whatever have you. If the "operator bool"
throws or returns false, then I have to manually destroy the object in
the return slot.
Here's my compiler patch:
https://github.com/healytpk/gcc-thomas-healy/commit/tag_return_if
And here's a GodBolt you can play around with:
https://godbolt.org/z/4P8o16Toz
Note that the GodBolt contains an example using 'std::expected' as
suggested by Simon, so you would do: return * if Func();
If anyone reading this post thinks the idea of patching compilers to
implement new features is cool but just way too difficult and complex,
I strongly suggest that you give it a go with the help of ChatGPT.
Give an outline of your idea to ChatGPT and ask if it would be very
complicated to implement it in your favourite open-source compiler.
Next ask what's the very first function you would edit in which file
in the compiler repository; this conversation can go on for many hours
over many days, and you'll hit Rebuild on your compiler dozens of
times and encounter lots of ICE's (internal compiler errors), but
really it's worth it and it's a lot of fun. I myself have never worked
as a compiler writer and I wouldn't be able to pull this off at the
moment without the help of an LLM. Now that I've written
'chimeric_ptr' and "return if" into the GNU g++ compiler, I'm getting
a little more familiar with it, so maybe in the future I'll reach a
point where I don't need the LLM, but for the time being I'm learning
a lot. I suggest you give it a go, I'm getting on very well with
ChatGPT v5.2 set in "Extended Thinking" mode. I'm not paid or rewarded
in any way by the makers of ChatGPT.
>
> So to break it down logically, here's what's going on:
>
> auto const retval = SomeFunction();
> if ( static_cast<bool>(retval) ) return retval;
>
> Now personally I think that this would be much more succinctly
> expressed as follows:
>
> return if SomeFunction();
I have written "return if" into the GNU g++ compiler. There are two
possible syntaxes:
return if expr;
return @ if expr;
In the second syntax, the @ symbol is any one of the unary operators:
+ - ! ~ * &
The second form with the unary operator was easier to code into the
compiler, as I didn't have to worry about whether or not the return
type was immovable-and-uncopiable, because if "operator@" returns a
PRvalue then it just gets returned as a PRvalue (because C++23
guarantees RVO).
The first form without the unary operator took a little more work. I
had to consider if the return value went in registers or in memory
(because normally on x86-64, it goes in RAX and RDX). When dealing
with a function that returns an immovable-and-uncopiable type by
value, the return value will never go in registers -- it will go in a
"return slot" whose address is typically passed in the first register
(i.e. RDI on x86-64 System V), so I had to manually manipulate the
return slot. Thankfully I didn't have to manually manipulate the RDI
register as the GNU g++ compiler allowed me to work at a higher level
than that, so I think my patched compiler should work fine if built
for aarch64 or x86_32 or whatever have you. If the "operator bool"
throws or returns false, then I have to manually destroy the object in
the return slot.
Here's my compiler patch:
https://github.com/healytpk/gcc-thomas-healy/commit/tag_return_if
And here's a GodBolt you can play around with:
https://godbolt.org/z/4P8o16Toz
Note that the GodBolt contains an example using 'std::expected' as
suggested by Simon, so you would do: return * if Func();
If anyone reading this post thinks the idea of patching compilers to
implement new features is cool but just way too difficult and complex,
I strongly suggest that you give it a go with the help of ChatGPT.
Give an outline of your idea to ChatGPT and ask if it would be very
complicated to implement it in your favourite open-source compiler.
Next ask what's the very first function you would edit in which file
in the compiler repository; this conversation can go on for many hours
over many days, and you'll hit Rebuild on your compiler dozens of
times and encounter lots of ICE's (internal compiler errors), but
really it's worth it and it's a lot of fun. I myself have never worked
as a compiler writer and I wouldn't be able to pull this off at the
moment without the help of an LLM. Now that I've written
'chimeric_ptr' and "return if" into the GNU g++ compiler, I'm getting
a little more familiar with it, so maybe in the future I'll reach a
point where I don't need the LLM, but for the time being I'm learning
a lot. I suggest you give it a go, I'm getting on very well with
ChatGPT v5.2 set in "Extended Thinking" mode. I'm not paid or rewarded
in any way by the makers of ChatGPT.
Received on 2026-02-05 11:46:19
