Date: Sat, 18 Apr 2026 23:15:06 +0800 (CST)
At 2026-04-18 00:51:28, "Thiago Macieira" <thiago_at_macieira.org> wrote:
>On Thursday, 16 April 2026 22:36:37 Pacific Daylight Time Zhao YunShan wrote:
>> 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.
>
>The problem is not *opposition* to the feature. There is no presumption of
>acceptance of a new feature. Each one must justify itself. There's no way
>around writing a technical paper explaining the motivation, the feature, the
>alternatives, and the technical language, then defending it.
I can tell you the answer you're looking for.
First, Interceptors are worth adding to the C++ standard.
So, let me ask you the same question: Are Interceptors worth adding to the C++ standard?
Answer with a single word: Yes or No. No explanations, no arguments.
The core motivation for adding Interceptors is to push the boundaries of the C++ ecosystem and make daily development more efficient.
It enables C++ developers to utilize standardized Interceptors directly¡ªwithout relying on third-party libraries or complex low-level hacks¡ªthereby lowering the barrier to entry for implementing these features.
Furthermore, the syntax design of Interceptors is inherently semantic. Its readability far surpasses that of traditional interception implementations. Developers can grasp the business intent of the logic at a glance, without needing to repeatedly consult documentation or trace low-level details, which significantly reduces the cognitive load of code maintenance
>If you don't do that or find someone to do it for you, it will not be added to
>the Standard.
>
>The point of this is not to make it a bureaucracy. The point is to make you
>and the committee think of the advantages and disadvantages of the feature.
>And I can tell you have not thought of all the limitations that apply, because
>you have consistently dismissed them when pointed out. The exercise is
>supposed to help you write a better feature that has fewer limitations and
>helps improve the language further than your first idea would have.
The committee should maintain a more professional and technical stance. Some of the questions and responses always sound like excuses.
I proposed this two years ago, and today, progress remains at zero. Since some claim that Interceptors are useful, why haven't they pushed to get this proposal into the Standard?
If the committee were truly serious about this, it wouldn't have taken this long, nor would they still be nitpicking.
Thiago, I don't need your lectures, and you're in no position to teach me. I hope you can come up with a solution that is actually convincing and earns some respect.
>--
>Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
>On Thursday, 16 April 2026 22:36:37 Pacific Daylight Time Zhao YunShan wrote:
>> 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.
>
>The problem is not *opposition* to the feature. There is no presumption of
>acceptance of a new feature. Each one must justify itself. There's no way
>around writing a technical paper explaining the motivation, the feature, the
>alternatives, and the technical language, then defending it.
I can tell you the answer you're looking for.
First, Interceptors are worth adding to the C++ standard.
So, let me ask you the same question: Are Interceptors worth adding to the C++ standard?
Answer with a single word: Yes or No. No explanations, no arguments.
The core motivation for adding Interceptors is to push the boundaries of the C++ ecosystem and make daily development more efficient.
It enables C++ developers to utilize standardized Interceptors directly¡ªwithout relying on third-party libraries or complex low-level hacks¡ªthereby lowering the barrier to entry for implementing these features.
Furthermore, the syntax design of Interceptors is inherently semantic. Its readability far surpasses that of traditional interception implementations. Developers can grasp the business intent of the logic at a glance, without needing to repeatedly consult documentation or trace low-level details, which significantly reduces the cognitive load of code maintenance
>If you don't do that or find someone to do it for you, it will not be added to
>the Standard.
>
>The point of this is not to make it a bureaucracy. The point is to make you
>and the committee think of the advantages and disadvantages of the feature.
>And I can tell you have not thought of all the limitations that apply, because
>you have consistently dismissed them when pointed out. The exercise is
>supposed to help you write a better feature that has fewer limitations and
>helps improve the language further than your first idea would have.
The committee should maintain a more professional and technical stance. Some of the questions and responses always sound like excuses.
I proposed this two years ago, and today, progress remains at zero. Since some claim that Interceptors are useful, why haven't they pushed to get this proposal into the Standard?
If the committee were truly serious about this, it wouldn't have taken this long, nor would they still be nitpicking.
Thiago, I don't need your lectures, and you're in no position to teach me. I hope you can come up with a solution that is actually convincing and earns some respect.
>--
>Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Received on 2026-04-18 15:15:14