Date: Sun, 1 Jun 2025 23:37:14 -0400
When we criticize the committee’s direction, it is only to help C++ remain relevant—it is because we care.
A technology, such as a compiler, language, etc. does not exist in a vacuum; it serves a real-world business goal. It is the real-world decisions, business and political, that determine if a technology remains “relevant,” not the other way around. A business decision doesn’t care about which committee, language, compiler, ISA, etc. It only cares about the bottom line. For example, if it is too expensive, they switch to something else.
If it is “portable” then as said, it can remain a library outside of the standard. There is nothing special about this proposal. I have been against most additions to C++ standard in recent years, and I am not alone in that. I wasn’t a committee member back then, but now I have one vote. I understand my views are not popular, but being popular is not one of my life goals; however, it is crucial and required for the committee to hear different opposing perspectives.
Hopefully I won’t need to repeat myself in the future. When I oppose something, unless otherwise stated, the reason will be: “I think it isn’t needed in the standard. We can almost never remove what we put in, so frugality is wisdom.”
Hopefully, the majority will tolerate the opposition of a minority of naysayers.
Thank you
> On Jun 1, 2025, at 12:45, Jan Schultke <janschultke_at_[hidden]> wrote:
>
> Jens has already answered these concerns for the most part, but here
> are some missing things:
>
>> Features makes C++ bigger/harder to support
>
> The proposed functions can be implemented as pure library features
> with no dependence on intrinsics. The only hardware dependence is that
> fundamental operations like / and * have to work, but that's required
> of any conforming C++ implementation anyway, as Jens said.
>
> Given that ceiling integer division is well-motivated, commonly
> implemented (incorrectly) by users, and almost trivial to implement,
> it's a good fit for the standard library.
>
>> So why the same reason that would make WG 14 not want it in the standard not apply here?
>
> Because the feature is too portable. It's not really abstracting from
> hardware like <bit>, just providing utility. I'm not sure if WG14 is
> open to adding library features that can reasonably exist outside the
> standard library.
>
> Again, these are entirely different languages with different
> committees, different design standards, different use cases,
> different users.
A technology, such as a compiler, language, etc. does not exist in a vacuum; it serves a real-world business goal. It is the real-world decisions, business and political, that determine if a technology remains “relevant,” not the other way around. A business decision doesn’t care about which committee, language, compiler, ISA, etc. It only cares about the bottom line. For example, if it is too expensive, they switch to something else.
If it is “portable” then as said, it can remain a library outside of the standard. There is nothing special about this proposal. I have been against most additions to C++ standard in recent years, and I am not alone in that. I wasn’t a committee member back then, but now I have one vote. I understand my views are not popular, but being popular is not one of my life goals; however, it is crucial and required for the committee to hear different opposing perspectives.
Hopefully I won’t need to repeat myself in the future. When I oppose something, unless otherwise stated, the reason will be: “I think it isn’t needed in the standard. We can almost never remove what we put in, so frugality is wisdom.”
Hopefully, the majority will tolerate the opposition of a minority of naysayers.
Thank you
> On Jun 1, 2025, at 12:45, Jan Schultke <janschultke_at_[hidden]> wrote:
>
> Jens has already answered these concerns for the most part, but here
> are some missing things:
>
>> Features makes C++ bigger/harder to support
>
> The proposed functions can be implemented as pure library features
> with no dependence on intrinsics. The only hardware dependence is that
> fundamental operations like / and * have to work, but that's required
> of any conforming C++ implementation anyway, as Jens said.
>
> Given that ceiling integer division is well-motivated, commonly
> implemented (incorrectly) by users, and almost trivial to implement,
> it's a good fit for the standard library.
>
>> So why the same reason that would make WG 14 not want it in the standard not apply here?
>
> Because the feature is too portable. It's not really abstracting from
> hardware like <bit>, just providing utility. I'm not sure if WG14 is
> open to adding library features that can reasonably exist outside the
> standard library.
>
> Again, these are entirely different languages with different
> committees, different design standards, different use cases,
> different users.
Received on 2025-06-02 03:37:40