Jonathan Wakely wrote:
> So you can't use contract checks as performance hints
> in your code without disabling checks at API boundaries between
> untrusted (or less trusted, or less tested) components.

My understanding is that the preferred idiom is to perform contract
checks first, then use `assume` or analogous features for performance
optimization, as in the following example.

template<size_t ByteAlignment>
void foo(span<float> x)
  pre(std::is_sufficiently_aligned<ByteAlignment>(x.data())
{
  span x_a(std::assume_aligned<ByteAlignment>(x.data());
  // ... compute with x_a ...
}

Is that right?

Thanks!
mfh

On Thu, Apr 2, 2026 at 5:49 AM David Brown via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Thank you for that - it does clarify things for me. It is usually the
> case for new C++ features that the initial introduction is somewhat
> limited, and later standard versions extend them as details are fleshed
> out and both users and implementers get some experience about what is
> actually useful in practice, and what people would like to see added.
> But it is helpful to hear about what is already in planning.
>
> (I seem to be having a little trouble with my email sending at the
> moment. I apologise if that results in any duplicates, or if it only
> gets to some of the addressees.)
>
> David
>
>
> On 02/04/2026 13:04, Jonathan Wakely wrote:
> >
> >
> > On Tue, 31 Mar 2026 at 09:05, Jonathan Wakely <cxx_at_[hidden]
> > <mailto:cxx_at_[hidden]>> wrote:
> >
> >
> > And since the version of contracts we have in C++26 only allows them
> > to be enabled globally or disabled globally, for the whole program,
> > you don't get to choose which API boundaries have checks enabled and
> > which don't. So you can't use contract checks as performance hints
> > in your code without disabling checks at API boundaries between
> > untrusted (or less trusted, or less tested) components.
> >
> >
> > I was asked about this statement off-list, and should clarify what I meant.
> >
> > Contracts in C++26 do allow an implementation to provide more
> > granularity so that different assertions (or different TUs, or different
> > libraries) can use different evaluation semantics. But what was
> > standardized for C++26 (the Minimum Viable Product of C++ Contracts)
> > doesn't provide any syntax or other mechanism for doing that.
> >
> > So what I wrote isn't really accurate. C++26 does *allow* them to be
> > enabled or disabled non-globally, but just allowing it doesn't actually
> > make it possible. You can't do it in portable C++26 code. And you can't
> > do it in the implementation that's about to ship in GCC 16 (adding
> > support for labels as an extension could be added in future, but isn't
> > supported today).
> >
> > So if you absolutely require the ability to use different evaluation
> > semantics in different places (and many people do require that), then
> > you'll need to wait for C++29 which is expected to provide features for
> > doing that. It was always made clear that C++26 contracts would not
> > provide every feature on day one, and that some use cases would be
> > supported later. They're still useful for other use cases today, just
> > not all use cases.
> >
> >
> >
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals