Interceptors make the life easier for some. But they also take away from the purity of the language. They make reasoning about it more involved, because another function may be called. They change the underlying programming model to a more imperative one.   Depending on how they are implemented  - they cannot be easily combined with other Interceptors to the same function - at least there are ordering issues  - it is a static facility, many would prefer runtime configuration  - many would prefer object-oriented wrappers, which are easier to create with reflection and meta-programming  - they possibly violate the access model (private+protected) of classes  - they may interact with contracts, if they change preconditions  - they may badly interact with libraries  - many would have done interceptors a different way, perhaps even the implementors   Even if you get a good solution with your proposal, there will always be compromises and different opinions how the language should look like.   Just describe usages and who uses and needs them; and why it should be standardized instead of each implementation having their own Interceptors. Describe which facilities the existing implementations have.     -----Ursprüngliche Nachricht----- Von:Zhao YunShan via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 17.04.2026 07:37 Betreff:Re: [std-proposals] Interceptor Function An:Thiago Macieira <thiago_at_[hidden]>; CC:Zhao YunShan <dou1984_at_[hidden]>; std-proposals_at_[hidden];     I get your point, but here is how I would write that paper: Line 1: The C++ Committee is introducing Interceptors. Line 2: Everyone applauds. I don't think anyone would oppose adding such a practical feature; C++ developers have been waiting for this for too long. Don't let the bureaucracy of a "paper" dampen the urgency of the need. If Interceptors actually make it into the Standard, I believe everyone will applaud. At 2026-04-17 12:46:34, "Thiago Macieira" <thiago_at_[hidden]> wrote: >On Thursday, 16 April 2026 20:39:20 Pacific Daylight Time Zhao YunShan wrote: >> Because Interceptors add a critical capability and make coding tasks -- such >> as hooking, stubbing, tracing, and auto-locking -- sufficiently easier, >> alongside other qualitative advantages. The problems Interceptor is solving >> are sufficiently common. > >> Why did the US send astronauts to the Moon? Why is Musk sending humans to >> Mars? Why does NASA launch so many satellites? These projects cost a >> fortune, yet they bring little tangible economic benefit. So, were they >> worth it? And you shouldn't be asking me this. You should ask the Java and >> Python developers—ask them if Interceptors are worth it. Stop asking such >> subjective questions to anyone, anywhere, anytime. It's completely >> meaningless. > >I'm not asking this to annoy you. I am asking you this to make you think of >the answers, because you're going to have to write them in the paper that >justifies their inclusion in the Standard, along with the technical details of >how they work > >-- >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