Hi Zhao,   you and Frederick target different features. You want a compiled feature for newly compiled code, Frederick a linker feature for already compiled code or code where the source is not available. Your feature would work with inline code, Frederick's only at ABI compliant function call boundaries.   At least that is what I understand.   So a proposal would have to decide, which use cases it covers at all and whether the standard is the right place for it. And how future-proof it is. Modules, more and more link-time optimizations, contracts with checked pre- and post-conditions, metaprogramming: A simple function call could get more involved. If only some calls are intercepted and it depends on the compiler and build configuration, which, is the standard the right place for it? Can the same be achieved or at least made easier with reflection by creating a wrapper class? Who decides that a class is intercepted? The class? The calling code? The complier command-line? The build makefile? The linker command-line? A debugger at runtime?   Best, Sebastian   -----Ursprüngliche Nachricht----- Von:Zhao YunShan via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mi 15.04.2026 14:46 Betreff:Re: [std-proposals] Interceptor Function An:Thiago Macieira <thiago_at_[hidden]>; CC:Zhao YunShan <dou1984_at_[hidden]>; std-proposals_at_[hidden];   At 2026-04-15 01:00:42, "Thiago Macieira" <thiago_at_[hidden]> wrote: >On Tuesday, 14 April 2026 06:31:22 Pacific Daylight Time Zhao YunShan via Std- >Proposals wrote: >> First, replacing function symbol at link time is a proven approach; g++ >> --wrap has been doing this for years. Promoting this compiler flag feature >> to a native language feature would enhance code readability and make it >> effortless for developers to apply. Why not do it? > >Why does it have to be a *Standard* feature? I'm not doubting the usefulness, >I'm just asking whether it needs to be in the Standard. If you're asking whether it's mandatory to add Interceptors to the C++ standard, the answer is definitely no. But I have a question for you in return: C can technically achieve everything C++ does, so why is C++ considered necessary? C++98 can do everything C++11 does, so why do we even need C++1x, C++2x, and beyond?  >See also Sebastian's reply, showing there are different interception techniques >for different conditions, none of which the Standard is aware of. There's no >way to have a *single* native language feature that will work for all of those >conditions. So is it worth standardising one way of interception that doesn't >always work?   The solutions I proposed are all implemented purely at the language code level (except for the process of swapping function symbols/names, but I assume that isn't too difficult). If older compilers support this code, why would the differences in OS linking methods you mentioned even come into play? >-- >Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > Principal Engineer - Intel Data Center - Platform & Sys. Eng. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals