I've already gotten the answer I wanted, so anything you say now is meaningless.
You monopolize the submission of proposals, dictate paper publications, and control the release of standards. You shut good proposals out just because you feels they aren't "worthy," or sometimes, simply to vent your frustration.
It's just that the quality of the standard has dropped drastically since C++20. Old problems are constantly mentioned as still unsolved, while new ones keep emerging. std::execution is still unable to become the mainstream in development, yet the committee still expects it to replace third-party libraries, forcing everyone to use its buggy features. I feel that the people who proposed and passed that motion have never participated in a large-scale project. If they had, they would definitely know where the biggest problems in C++ lie¡ªwhere the networking issues are, and where the coroutine issues are.
My proposals aren't just about Interceptors; they also include switch(string) and coroutines. The reason I dare to stand up to you guys is that my designs are robust enough, while you can't come up with a single solution yourselves and instead go out of your way to nitpick.
You always trouble proposers with subjective questions like "Is this proposal worthy?" I'm curious, since you aren't even a committee member, why are you so confident that my proposal is unworthy and will never be written as a formal proposal? This isn't just bureaucracy; 99% of the time, you are doing harm.
So I also want to ask: for a committee that always adds half-baked features and blocks good ones, do we really need it? Is it worth placing our hopes and expectations on such a committee?
I hope the committee gives me a credible reply, although I don't hold out any hope for it.


At 2026-04-19 00:56:28, "Thiago Macieira" <thiago@macieira.org> wrote:
>On Saturday, 18 April 2026 09:29:06 Pacific Daylight Time Zhao YunShan wrote:
>> So you're saying Interceptors are worthless and this whole thing is
>> pointless?
>
>No, I did not say that.
>
>I am saying *I* do not see sufficient value in it, based on my uses, to make it 
>a Standard feature. I think that extensions are just fine. And based on my 
>experience, I think this feature would come up short in real-world because of 
>differences in how executables and libraries are compiled and linked.
>
>While I don't see sufficient value in the feature, I am not *opposed* to it. If 
>you can write a good proposal that does improve the language, it deserves a 
>chance to be adopted. Therefore, I am offering advice on how to make it better.  
>Because the thing I don't want is that a defective proposal be adopted, which 
>would be a detriment to the language and developers.
>
>Mind you: I did not say your proposal is defective. I said it has rough edges 
>that you need to polish first, and there are a lot of constraints and 
>limitations that you need to describe.
>
>-- 
>Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>  Principal Engineer - Intel Data Center - Platform & Sys. Eng.