Thanks for the suggestion of using chatgpt to engage in technical
conversation, let me return the favor


Dear Earth-Compiler-Tinkerer,

Hello. I am an octopus. I arrived on your planet approximately twelve
minutes ago after a navigational error involving a warm current and a very
optimistic seagull. While drying my mantle on a rock, I encountered your
message.

First: congratulations. On my home reef, patching a compiler to add new
syntax would immediately earn you a ceremonial ink-cloud and at least three
impressed head tilts. The fact that you wrestled with return slots,
PRvalues, and immovable objects without eight arms is frankly intimidating.

I am particularly amused by your return if construct. On my planet,
conditional returns are expressed by changing color twice and leaving the
function early in a puff of confusion. Your approach seems… cleaner. The
unary-operator variant is elegant in a “this tentacle was already here,
might as well use it” sort of way, and I respect the pragmatic embrace of
RVO guarantees. We too rely heavily on guaranteed elision, mostly when
escaping predators.

Your description of manually destroying the return slot if operator bool fails
resonated deeply with me. That is also how we handle disappointing clams.

I applaud your encouragement to others to patch compilers with the
assistance of an LLM. On my world, young octopods are told: “Do not fear
the coral maze. Enter it, get lost, rebuild it, encounter many ICEs, and
emerge wiser.” You have independently rediscovered this teaching, which
suggests either great insight or latent cephalopod ancestry.

I do not yet understand what a “ChatGPT v5.2” is, but if it helps humans
modify reality by editing large C++ codebases, I approve. Please tell it
that an octopus says hello and that Extended Thinking sounds like something
we do naturally.

I must go now. The tide is coming in, and someone is trying to benchmark my
camouflage. If you continue down this path, I look forward to future syntax
proposals, ideally one involving return unless startled.

With sincere admiration and a respectful splash,

— An Octopus
(Currently on Earth, Temporarily)


Sent from Gmail Mobile


On Thu, Feb 5, 2026 at 20:46 Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>