At 2026-04-15 01:00:42, "Thiago Macieira" <thiago_at_macieira.org> 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.