P2900 and macros meet the needs of Functional Safety because Functional
Safety does not rely on things working accidentally -- they're always
tested by experts to the point where statistically speaking bugs don't
exist. Everything's redundantly checked at multiple levels.

This cannot change even with improved Language Safety because the semantics
of Functional Safety are things the Language can never know about. There
will never be a safety critical software system that isn't built by experts
and redundantly checked and tested.

On Mon, Oct 20, 2025 at 1:56 PM John Spicer <jhs_at_[hidden]> wrote:

> Macros are different from contracts because:
>
> 1. You can make sure that you get consistent behavior when the contracts
> are in headers (the mail topic of this thread).
>
> 2. You can choose whether or not exceptions are mapped into contract
> violations
>
> 3. You can choose the violation handler that you want to be used
>
> 4. Expressions silently change meaning (constification)
>
> 5. Because of #2, you don’t necessarily end up with massive code for each
> contract check
>
> 6. Different pieces of code can use different semantics in a transparent
> mechanism.
>
> They don’t address the needs of Functional Safety because you don’t know
> whether they will actually be checked in any given case.
>
> John.
>
>
> On Oct 20, 2025, at 4:08 PM, Ryan McDougall <mcdougall.ryan_at_[hidden]>
> wrote:
>
> They are comparable because they both address the needs of Functional
> Safety as per p3578 <http://wg21.link/p3578>. SG23 took a poll on whether
> they're better than macros see P3297 <http://wg21.link/P3297>.
>
> I think it's not a leap of logic that EWG has strong consensus to pass
> P2900 precisely because they feel it's strictly better than macros.
>
> Cheers,
>
> On Mon, Oct 20, 2025 at 12:58 PM John Spicer <jhs_at_[hidden]> wrote:
>
>> We have never taken a poll of whether P2900 is better then macro
>> solutions.
>>
>> Could you explain why you think contracts and macro-based solutions are
>> comperable?
>>
>> John.
>>
>> On Oct 20, 2025, at 3:09 PM, Ryan McDougall <mcdougall.ryan_at_[hidden]>
>> wrote:
>>
>> I’m saying we have decades of experience with macro based systems, which
>> defines the floor of features/expectations. The consensus is P2900 is
>> better taken as a whole. There are things i think should be different with
>> p2900, but p2900 represents consensus. There has been no evidence put
>> forward that there is a more correct course. Based on those decades of
>> experience here are no outstanding questions that having a TS would answer.
>>
>> If i am wrong, please list precise questions that a TS would answer. “We
>> don’t have enough experience” is a statement.
>>
>> Cheers,
>>
>> On Mon, Oct 20, 2025 at 11:54 AM John Spicer <jhs_at_[hidden]> wrote:
>>
>>> You keep saying things like we have “decades of experience with
>>> macro-based systems”.
>>>
>>> If contracts were remotely similar to macro-based systems, we would not
>>> be having this discussion.
>>>
>>> The problem is that contracts are *vastly* different.
>>>
>>> If you put P2900 and macro-based systems in the same set, that means you
>>> don’t understand one or the other.
>>>
>>> John.
>>>
>>> On Oct 20, 2025, at 2:22 PM, Ryan McDougall via SG21 <
>>> sg21_at_[hidden]> wrote:
>>>
>>> The "course corrections" do not actually suggest a future course (beyond
>>> asserting without evidence"we need more experience" and kicking the can
>>> down the road to a TS) -- we've had years for alternative proposals to be
>>> put forward, and none have surpassed P2900.
>>>
>>> We *do* have decades of experience with macro-based systems, we *do*
>>> have decades of experience building software at scale (see Software
>>> Engineering at Google <https://abseil.io/resources/swe-book>), and we
>>> *do* know who our users are (see P1995 and P3297) -- and while there are
>>> many variations on contracts, P2900 represents our best consensus
>>> interpretation of those decades of experience. Not all of these decisions
>>> were everyone's first choice, but P2900 is the consensus. There is no
>>> evidence that any other option would improve that.
>>>
>>> Multiple papers, like P2900 and P3578 <http://wg21.link/p3578> explain
>>> exactly who the feature is for, and how and why each of these design
>>> choices were made. There is no reason to believe the current course is
>>> incorrect, or that another course would be more correct.
>>>
>>> On Mon, Oct 20, 2025 at 4:58 AM Ville Voutilainen via SG21 <
>>> sg21_at_[hidden]> wrote:
>>>
>>>> On Mon, 20 Oct 2025 at 14:34, Timur Doumler via SG15
>>>> <sg15_at_[hidden]> wrote:
>>>> > Given the above, it seems to me like opposing C++26 contract
>>>> assertions because you want that checks are always on / always enforced is
>>>> kinda like this:
>>>> >
>>>> > – Alice: "I want safer roads for pedestrians." (reasonable and good
>>>> request)
>>>> > – Bob: "Here's a proposal to fund bike lanes in the city."
>>>> (reasonable and good proposal roughly in the same area but with a different
>>>> goal)
>>>> > – Alice: "But bike lanes don't add more crosswalks or reduce speed
>>>> limits. So they don't make roads safer for pedestrians. Therefore, we
>>>> should not build bike lanes."
>>>> >
>>>> > Here, Alice is committing a logical fallacy. Just because bike lanes
>>>> are not useful for Alice, it doesn't mean that they're not useful for Bob,
>>>> and taking away bike lanes from Bob does nothing to give Alice what she
>>>> wants.
>>>>
>>>> The colorful analogy doesn't include considerations where providing
>>>> bike lanes for Bob and doing nothing else is not entirely harmless for
>>>> the pedestrians Alice is focused on.
>>>>
>>>> It's also incorrect in its suggestion that bike lanes are not useful
>>>> for Alice. Nobody has said that P2900 isn't useful. That's why it's
>>>> included
>>>> in *every* *single* *one* of the currently active proposals suggesting
>>>> course corrections.
>>>> _______________________________________________
>>>> SG21 mailing list
>>>> SG21_at_[hidden]
>>>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
>>>> Link to this post: http://lists.isocpp.org/sg21/2025/10/11436.php
>>>>
>>> _______________________________________________
>>> SG21 mailing list
>>> SG21_at_[hidden]
>>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
>>>
>>> Link to this post: http://lists.isocpp.org/sg21/2025/10/11499.php
>>>
>>>
>>>
>>
>