Date: Tue, 28 Apr 2026 12:10:07 +0100
On Tue, 28 Apr 2026 at 11:06, Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> wrote:
>
>
> On Tuesday, April 28, 2026, Jonathan Wakely wrote:
>
>>
>>>>
>> The interceptor is declared as void, but it actually returns whatever the
>> 'goto' statement returns? Why not declare it as auto or decltype(auto)?
>>
>
>
>
> An interceptor function doesn't return. It jumps.
>
Yes, but your proposed syntax is a function declared as type void(), which
you then need to cast to a different type. That's disgusting.
Once again you're entirely focussed on how this could be implemented, and
the actual feature you're proposing is terrible.
>
> Yes under the hood I have implemented it as two separate functions, a core
> and a thunk, and the core returns a value to the thunk, but that's all
> secretive under the hood stuff specific to my GNU patch. The guys at
> Microsoft or Embarcadero (formerly Borland) might just make it one
> function. I could have made it be just one function -- and actually I bet I
> could feed my entire compiler patch into ChatGPT and ask it to make that
> adjustment, and it might even get it right the first time or 2nd or 3rd
> time. I like the simplicity though of my implementation.
>
I don't care about the implementation in the slightest. Obviously this can
be implemented, it's simple. The problem is that it doesn't fit into the
design of the language, it's just a nasty hack to wrap an inline assembly
trick into something portable that roughly looks like C++ syntax, but
completely ignoring the type system to just use void() and casts to a
different function type (which would then be UB to invoke, without new
language rules to carve out an exception for this).
So this is a completely new type of function that doesn't fit the existing
type system, but is declared as though it's a normal function, except for
an attribute.
Well done, you've created a trampoline that has killed a real C++ function
and is wearing its face as a mask.
>
> As far as the C++ programmer is concerned though, the inceptor function
> just jumps to another function -- and I thought the simplest way to express
> this would be to give it the signature "void Func(void)" and to use the
> syntax "goto ->".
>
>
>
>
>> This is horrible. Why would I ever want to write this? You have to name
>> std::printf inside the interceptor, *and* cast its type to std::printf when
>> you use it? That's horrible.
>>
> <snip>
>
>>
>> Why is this horribleness better than just wrapping std::printf in a
>> lambda?
>>
> <snip>
>
>
>> What's the benefit of your interceptor?
>>
>
>
>
> I agree with you on all counts . . . a template lambda with a forwarding
> parameter pack is supreme over an interceptor function in every way --
> including aesthetic horridness and horribleness -- except in cases where
> you don't know (or don't care about) the signature of the target function...
>
How is the lambda I showed dependent on the target function, except for
using its name?
> or if you want to write one interceptor which can be used with many
> different target function signatures.
>
How does 'goto -> std::printf' work with different target function
signatures?
>
> If you want to be agnostic to the target function signature, you must
> preserve the stack and all registers that might be used for passing
> arguments. That's exactly what my interceptor does.
>
> An interceptor will be very useful when dealing with pre-compiled
> proprietary libraries (for which you don't have the source code or even a
> header file), and also for dealing with other languages such as Haskell.
>
std-proposals_at_[hidden]> wrote:
>
>
> On Tuesday, April 28, 2026, Jonathan Wakely wrote:
>
>>
>>>>
>> The interceptor is declared as void, but it actually returns whatever the
>> 'goto' statement returns? Why not declare it as auto or decltype(auto)?
>>
>
>
>
> An interceptor function doesn't return. It jumps.
>
Yes, but your proposed syntax is a function declared as type void(), which
you then need to cast to a different type. That's disgusting.
Once again you're entirely focussed on how this could be implemented, and
the actual feature you're proposing is terrible.
>
> Yes under the hood I have implemented it as two separate functions, a core
> and a thunk, and the core returns a value to the thunk, but that's all
> secretive under the hood stuff specific to my GNU patch. The guys at
> Microsoft or Embarcadero (formerly Borland) might just make it one
> function. I could have made it be just one function -- and actually I bet I
> could feed my entire compiler patch into ChatGPT and ask it to make that
> adjustment, and it might even get it right the first time or 2nd or 3rd
> time. I like the simplicity though of my implementation.
>
I don't care about the implementation in the slightest. Obviously this can
be implemented, it's simple. The problem is that it doesn't fit into the
design of the language, it's just a nasty hack to wrap an inline assembly
trick into something portable that roughly looks like C++ syntax, but
completely ignoring the type system to just use void() and casts to a
different function type (which would then be UB to invoke, without new
language rules to carve out an exception for this).
So this is a completely new type of function that doesn't fit the existing
type system, but is declared as though it's a normal function, except for
an attribute.
Well done, you've created a trampoline that has killed a real C++ function
and is wearing its face as a mask.
>
> As far as the C++ programmer is concerned though, the inceptor function
> just jumps to another function -- and I thought the simplest way to express
> this would be to give it the signature "void Func(void)" and to use the
> syntax "goto ->".
>
>
>
>
>> This is horrible. Why would I ever want to write this? You have to name
>> std::printf inside the interceptor, *and* cast its type to std::printf when
>> you use it? That's horrible.
>>
> <snip>
>
>>
>> Why is this horribleness better than just wrapping std::printf in a
>> lambda?
>>
> <snip>
>
>
>> What's the benefit of your interceptor?
>>
>
>
>
> I agree with you on all counts . . . a template lambda with a forwarding
> parameter pack is supreme over an interceptor function in every way --
> including aesthetic horridness and horribleness -- except in cases where
> you don't know (or don't care about) the signature of the target function...
>
How is the lambda I showed dependent on the target function, except for
using its name?
> or if you want to write one interceptor which can be used with many
> different target function signatures.
>
How does 'goto -> std::printf' work with different target function
signatures?
>
> If you want to be agnostic to the target function signature, you must
> preserve the stack and all registers that might be used for passing
> arguments. That's exactly what my interceptor does.
>
> An interceptor will be very useful when dealing with pre-compiled
> proprietary libraries (for which you don't have the source code or even a
> header file), and also for dealing with other languages such as Haskell.
>
Received on 2026-04-28 11:10:26
