Date: Mon, 20 Oct 2025 14:32:18 +0300
On Mon, 20 Oct 2025 at 14:29, Timur Doumler via SG15
<sg15_at_[hidden]> wrote:
>
> Hi John,
>
> I agree that the problem you highlighted exists. I don't think anybody dismisses the existence of the problem. However, as described in P3846, the fundamental cause of the problem is the way in which the C++ compilation model works, and not anything specific to contracts, and in fact *any* feature that lets you change the semantic of code at build time inevitably runs into the same problem (and many existing macros and semantic-modifying compiler flags do have that problem today and are stil being widely used).
>
> Now, as described in P3846, there are only three ways to address the problem:
>
> (1) Accept that the problem exists and standardise P2900 anyway because it provides value to users despite the existence of the problem,
>
> (2) Change P2900 to require deterministic semantics across TUs, which means the feature will not work with existing toolchains, which in turn means nobody will adopt it,
>
> (3) Not standardise P2900 or any other such feature at all.
P3846 is wrong, if it suggests that there's only three ways to address
the problem. That's missing a
4) provide an assertion that cannot change its meaning based on build flags.
"We'll do it in the future with labels" is not quite the same thing
when P2900 in C++26 will be in the hands of users
for multiple years, without those labels.
<sg15_at_[hidden]> wrote:
>
> Hi John,
>
> I agree that the problem you highlighted exists. I don't think anybody dismisses the existence of the problem. However, as described in P3846, the fundamental cause of the problem is the way in which the C++ compilation model works, and not anything specific to contracts, and in fact *any* feature that lets you change the semantic of code at build time inevitably runs into the same problem (and many existing macros and semantic-modifying compiler flags do have that problem today and are stil being widely used).
>
> Now, as described in P3846, there are only three ways to address the problem:
>
> (1) Accept that the problem exists and standardise P2900 anyway because it provides value to users despite the existence of the problem,
>
> (2) Change P2900 to require deterministic semantics across TUs, which means the feature will not work with existing toolchains, which in turn means nobody will adopt it,
>
> (3) Not standardise P2900 or any other such feature at all.
P3846 is wrong, if it suggests that there's only three ways to address
the problem. That's missing a
4) provide an assertion that cannot change its meaning based on build flags.
"We'll do it in the future with labels" is not quite the same thing
when P2900 in C++26 will be in the hands of users
for multiple years, without those labels.
Received on 2025-10-20 11:32:31
