Date: Mon, 20 Oct 2025 12:23:54 -0400
On Mon, Oct 20, 2025 at 12:16 PM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:
> On Mon, 20 Oct 2025 at 19:09, Joshua Berne <berne_at_[hidden]> wrote:
> >
> >
> >
> > On Mon, Oct 20, 2025 at 12:01 PM Ville Voutilainen <
> ville.voutilainen_at_[hidden]> wrote:
> >>
> >> The contracts specification specifies them to be compatible.
> >
> >
> > Where?
>
> Everywhere. Multiple definitions of inline functions with different
contract evaluation semantics are ODR-equivalent,
>
Where does the specification say that the definition of a contract
assertion has a contract evaluation semantic?
> multiple TUs in general can have whichever contract-evaluation
> semantics chosen by whichever implementation-defined
mechanism, but that mechanism must select one of the standardized
> semantics.
Where does anything in the specification say that there is a
contract-evaluation semantic chosen for a TU?
> And none of that is said to be in any way
> incompatible anywhere.
You seem to be claiming that things that aren't defined are not being
described as incompatible and that's a problem. Rules about things we
don't define seem like they would be a bigger problem.
> You can even have different evaluation
> semantics for different calls of the same function, defined
> just once, including defined in the same TU, and nowhere in the
> standard does anything say that any of that is incompatible
> in any way.
>
Yes, with full flexibility to the implementation to define how and when
that happens.
Implementations are also, because they are defining this, perfectly able to
say when the choices that dictate the evaluation semantics are or are not
compatible with one another.
Our specification is entirely about allowing the possibility of mixed modes
being supported by a compiler, but that same allowance also gives platforms
complete freedom to *not* support mixed modes of any sort. "Full stop" as
you might say.
I've now gone on with details and technical answers and the hopes of
clarifying things. Let me try one last time in a more succinct fashion
On Mon, Oct 20, 2025 at 12:16 PM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:
> Everywhere.
Since you've failed to provide an actual citation for a rule in the wording
itself, thank you for clarifying that this is not actually a rule in the
specification of C++26 contracts.
ville.voutilainen_at_[hidden]> wrote:
> On Mon, 20 Oct 2025 at 19:09, Joshua Berne <berne_at_[hidden]> wrote:
> >
> >
> >
> > On Mon, Oct 20, 2025 at 12:01 PM Ville Voutilainen <
> ville.voutilainen_at_[hidden]> wrote:
> >>
> >> The contracts specification specifies them to be compatible.
> >
> >
> > Where?
>
> Everywhere. Multiple definitions of inline functions with different
contract evaluation semantics are ODR-equivalent,
>
Where does the specification say that the definition of a contract
assertion has a contract evaluation semantic?
> multiple TUs in general can have whichever contract-evaluation
> semantics chosen by whichever implementation-defined
mechanism, but that mechanism must select one of the standardized
> semantics.
Where does anything in the specification say that there is a
contract-evaluation semantic chosen for a TU?
> And none of that is said to be in any way
> incompatible anywhere.
You seem to be claiming that things that aren't defined are not being
described as incompatible and that's a problem. Rules about things we
don't define seem like they would be a bigger problem.
> You can even have different evaluation
> semantics for different calls of the same function, defined
> just once, including defined in the same TU, and nowhere in the
> standard does anything say that any of that is incompatible
> in any way.
>
Yes, with full flexibility to the implementation to define how and when
that happens.
Implementations are also, because they are defining this, perfectly able to
say when the choices that dictate the evaluation semantics are or are not
compatible with one another.
Our specification is entirely about allowing the possibility of mixed modes
being supported by a compiler, but that same allowance also gives platforms
complete freedom to *not* support mixed modes of any sort. "Full stop" as
you might say.
I've now gone on with details and technical answers and the hopes of
clarifying things. Let me try one last time in a more succinct fashion
On Mon, Oct 20, 2025 at 12:16 PM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:
> Everywhere.
Since you've failed to provide an actual citation for a rule in the wording
itself, thank you for clarifying that this is not actually a rule in the
specification of C++26 contracts.
Received on 2025-10-20 16:24:08