Date: Mon, 20 Oct 2025 13:35:58 +0200
> On 20 Oct 2025, at 13:32, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
>
> On Mon, 20 Oct 2025 at 14:29, Timur Doumler via SG15
> <sg15_at_[hidden] <mailto: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.
That is not really an option 4, but rather a completely different feature, precisely because it loses the ability to change the semantic at build time. So really your option 4 is the same as my option 3: not standardise a feature that lets you change the semantic at build time.
Cheers,
Timur
>
> On Mon, 20 Oct 2025 at 14:29, Timur Doumler via SG15
> <sg15_at_[hidden] <mailto: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.
That is not really an option 4, but rather a completely different feature, precisely because it loses the ability to change the semantic at build time. So really your option 4 is the same as my option 3: not standardise a feature that lets you change the semantic at build time.
Cheers,
Timur
Received on 2025-10-20 11:36:09
