On 9/24/25 6:11 PM, Ville Voutilainen wrote:
> On Thu, 25 Sept 2025 at 00:49, Tom Honermann <tom_at_[hidden]> wrote:
>> On 9/24/25 10:26 AM, Ville Voutilainen via SG15 wrote:
>>> On Wed, 24 Sept 2025 at 17:06, Harald Achitz via SG15
>>> <sg15_at_[hidden]> wrote:
>>>> Having some interest on the build issue myself, I would be thankful to learn about the following topics:
>>>>
>>>> Will it be easily manageable to tell the linker: hey, give me libfoo with contract assertions enabled, and that is using this special contract handler? And get an error if libfoo in that flavor is not available, but only in others other configuration.
>>> I'm unaware of an implementation that allows you to choose the
>>> contract evaluation semantic at link time. There's been talk about
>>> that,
>>> but no implementation yet. And, as <see below>, you can't have
>>> per-library violation handlers. Except on Windows you might, which
>>> is yet another unanswered question in the face of lack of both
>>> implementation and deployment experience.
>>>
>>>> or is it only easily manageable when you build the whole source tree including dependencies with profiles / tripplets, or what ever your control file is.
>>> The contract evaluation semantic is chosen at compile-time. Which of
>>> course means it isn't always easily manageable when you don't
>>> (re-)compile every library you use.
>> Existing implementations select the contract evaluation semantic at
>> compile-time, but the standard does not distinguish between compile-time
>> or run-time selection except in the case of constant evaluation.
> Right. For questions about how to deploy the feature, I was perhaps
> overly implicit about talking about existing implementations,
> but that indeed was what I was describing (non-existent hypothetical
> implementations are not really relevant for deployment questions,
> despite that other mail that says things like "use strategy A", which
> won't work if such strategy A isn't implemented, and text
> in the standard, while theoretically interesting, becomes
> purely-academic when implementations ship something other than
> a different alternative that the standard also possibly allows).

On the other hand, considerations for existing non-hypothetical
deployment scenarios that are not optimally supported by existing
implementations seems quite relevant to me; particularly in the context
of NB comments that question the need for flexible implementation
strategies. Deployment considerations differ for embedded, mobile,
desktop, server, in-house, browser client (e.g., WASM), etc... Those
that seek to restrict implementation strategies risk optimal deployment
opportunity among these ecosystems. I've never had an expectation that
implementation strategies would not continue to evolve after the first
wave of C++26 implementations are complete; quite the opposite.

>
>> I agree that we lack implementation and deployment experience for
>> implementation strategies that delay contract evaluation semantic
>> selection until run-time. I remain quite interested in such strategies,
>> but unfortunately am not available to explore them myself. I expect that
>> current efforts in post-link optimization (PLO) will eventually yield a
>> good solution.
> Iain told me he has a PoC for link-time selectable semantics, which
> we'll get to merging in a couple of weeks.
That is absolutely fantastic. Thank you, Iain!
>
> But that approach won't solve all the issues and all the problems, it
> has very particular trade-offs that we already know aren't
> suitable for all audiences or all deployment environments.

Indeed. I specifically mentioned PLO because it has the potential to
reduce those trade-offs.

Tom.