C++ Logo

liaison

Advanced search

Re: [wg14/wg21 liaison] [isocpp-sg21] Telecon to review P2388R1 Minimum Contract Support: either Ignore or Check_and_abort

From: Jens Maurer <Jens.Maurer_at_[hidden]>
Date: Fri, 24 Sep 2021 21:58:52 +0200
On 24/09/2021 18.41, Ville Voutilainen wrote:
> On Fri, 24 Sept 2021 at 19:26, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
>> [Ville]
>>> Gaby, I must wonder whether your definition of "ignorable" is
>>> different from Jens's. To me, a requirement that
>>> a contract is syntax-checked and entities referred in it odr-used
>>> doesn't allow for anything that I would describe
>>> as "ignoring".
>>
>> I suspect both Jens and I are have the same understanding of "ignorable".
>> If the program is correct, then it didn't violate any diagnosable rule, consequently ignoring them would not violate any diagnosable rule.
>>
>> Am I misunderstanding the point you're hinting at? Any example to help?
>
> The intent of P2388 is that an ill-formed contract check is diagnosed,
> even if the contract check is not evaluated.

That's the same desire we have for (standard) attributes:
[[nodiscard(garbage)]] should be ill-formed, even though
the attribute is ignorable.

It turns out the mechanics of diagnostics are such that spitting
a warning for anything inside [[ ]] satisfies all the formal
requirements. As much as we might mourn the bad QoI.

Maybe the philosophical difference here is whether contracts
are part of (usual) program semantics (you can use them to
cause a termination, given the right settings, instead of
writing std::abort() yourself), or whether they're part of
the meta-framework around your program.

The "ignorable like attributes" approach certainly fits the
latter interpretation better.

> There are two ways to handle contracts, either 'ignore' them or
> 'enforce' them, but in both of those ways,
> the contract needs to be syntax-checked and it odr-uses the entities
> it refers to. Completely ignoring a contract
> would fail to diagnose violations of diagnosable rules. As far as
> practical examples go,
>
> bool mah_bucket_predicate(int x);
>
> void mah_funcshoon_takin_intzorz(int a, int b)
> [[pre: mah_bucket_predicate(a, b)]];
>
> is ill-formed, because the potentially-evaluated invocation of
> mah_bucket_predicate() is ill-formed, it doesn't take two arguments,
> it takes one.

> Andrzej, Gasper: the wording doesn't achieve this completely correctly. It says
> "An ignored correctness annotation test performs no operation. [Note:
> The predicate is potentially-evaluated (6.3). —end note] "
> Make that note normative.

Not needed, [basic.def.odr] p2 says that any expression is
potentially-evaluated unless <narrow list of exceptions>.

Jens

Received on 2021-09-24 14:59:04