On 28/04/2026 12:06, Frederick Virchanza Gotham via Std-Proposals 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.

It returns, as far as C++ is concerned. Whether it uses an assembly
"jmp" or "ret" opcode is irrelevant. Your "goto -> std::printf;" is
just "return std::printf(std::forward<T>(args)...);" with a syntax to
make it look like the tail-call optimisation compilers would perform anyway.

>
> 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... or if you want to write one interceptor which can be used
> with many different target function signatures.

Jonathan's lambda is independent of the function signature (by its
templating), and could be extended to be independent of the function
itself - unlike your "interceptor".

You are correct that the lambda needs to know the signature of the
function, at the call site (where the template lambda is instantiated).
Your method /also/ needs to know the signature of the function at the
call site, for the function pointer cast. (You need to know the
signature before calling the function no matter how this is done -
calling a function with a signature other than that of its definition is
UB.)

>
> 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.

You would only need to do that if the interceptor was separately
compiled. A templated lambda needs the template definition to be
visible when you call it. But it does not need the definition of the
"intercepted" function - that can be external. It only needs its
signature, but you need that anyway to make any kind of use of it.

Why do you think it is so important for the interceptor function to be
separately compiled and invisible to the calling code, yet general
enough to handle any function signatures? Where would that be an
essential feature?

The cost of getting that is /massive/ run-time inefficiency (time and
stack space) compared to the forwarding lambda template, breaking type
safety, truly horrible user-level code, and new syntaxes with
fundamental breakage from existing syntax. Oh, and if a change in a
platform's ABI adds new registers to the list of possible argument
registers (say, to support more SIMD types), that means ABI breakage for
anything using your interceptors and support for the updated ABI will
make the interceptor calls even slower and take even more stack space,
even when the called function did not use these new registers.

It is - IMHO - an extraordinarily complicated and ugly hack for a
totally non-existent issue. Certainly you haven't given the slightest
hint as to why anyone would want an "interceptor" function in the first
place, given existing C++ features.

>
> 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.
>

Can you give a /concrete/ example that is at least vaguely realistic,
where your "interceptor" would work and where Jonathan's lambda (or
other existing C++ methods) would not?


(By the way, I think you'd do a lot better if you spent more time
reading replies and less time writing passive-aggressive posts to people
- not me - that have been doing this stuff from before you were born.
Your obsession with AI slop does not match the experience and knowledge
of folk like Jonathan and many others on this mailing list - including
those that you have driven out.)