Date: Fri, 26 Sep 2025 10:24:53 +0300
On Fri, 26 Sept 2025 at 10:13, Timur Doumler via SG15
<sg15_at_[hidden]> wrote:
> Now, there is one interesting caveat here: further down the line, vendors may come up with new compiler and linker technology where the linker is somehow aware of the contract semantic (we can't do it through name mangling as all pointers to the same function still need to compare equal – we'd have to do it through some kind of side channel), and you could potentially do stuff like what you describe. To my best knowledge, we do not have that technology today. Importantly, C++26 contract assertions are specified in such a way that they allow such technology (and you'll be able to do more interesting things if and when that technology becomes available), but do not require it. They must not require it, because:
>
> 1. If a new language feature requires new tooling in order to be usable, the result will be that the feature simply won't be adopted by the community (see Modules) so that's a non-starter. A new language feature must be compatible with existing toolchains.
>
> 2. Even in a brave new world where new toolchains exist that are aware of contract semantics across different object files, you might still have to link against binaries that have been compiled before such technology existed, with whatever contract semantic baked into them at that time. That's just the same ABI compatibility problem we always had to deal with. Note that most people don't compile their entire program from source – at the very least you have to link against system libraries.
Link-time selection of contract evaluation semantics doesn't in and of
itself require the new technology you seem to be suggesting.
>> The C++26 Contracts do not support per-library violation handlers. But
>> on Windows you may end up getting such.
> Ville, are you referring to the usual thing with DLLs here (which I mentioned above) or is there something else going on here that I'm not aware of?
The usual thing with DLLs.
>>>> And is it even possible to have different contract handlers set, in dependencies, or do people make that up?
>
>>> I have no idea where such an idea would come from.
>
>
>> That a particular piece of code would like to define how violations in
>> it or in the code it calls are handled? The section "Local Violation
>> Handlers"
>> in P3400?
>
>
> Ville, P3400 is a potential C++29 extension, which is not the topic of discussion here. We're talking about what's in the C++26 working draft, where the contract-violation handler is always global (with the DLL caveat).
I don't know how you determine the topic of the discussion, but when
someone asks "are per-module or per-TU violation handlers a thing?",
and
someone comments "I have no idea where such an idea would come from",
I think it's rather on-topic to point out that such finer-grained
violation handlers have been considered and are on the roadmap for Contracts.
<sg15_at_[hidden]> wrote:
> Now, there is one interesting caveat here: further down the line, vendors may come up with new compiler and linker technology where the linker is somehow aware of the contract semantic (we can't do it through name mangling as all pointers to the same function still need to compare equal – we'd have to do it through some kind of side channel), and you could potentially do stuff like what you describe. To my best knowledge, we do not have that technology today. Importantly, C++26 contract assertions are specified in such a way that they allow such technology (and you'll be able to do more interesting things if and when that technology becomes available), but do not require it. They must not require it, because:
>
> 1. If a new language feature requires new tooling in order to be usable, the result will be that the feature simply won't be adopted by the community (see Modules) so that's a non-starter. A new language feature must be compatible with existing toolchains.
>
> 2. Even in a brave new world where new toolchains exist that are aware of contract semantics across different object files, you might still have to link against binaries that have been compiled before such technology existed, with whatever contract semantic baked into them at that time. That's just the same ABI compatibility problem we always had to deal with. Note that most people don't compile their entire program from source – at the very least you have to link against system libraries.
Link-time selection of contract evaluation semantics doesn't in and of
itself require the new technology you seem to be suggesting.
>> The C++26 Contracts do not support per-library violation handlers. But
>> on Windows you may end up getting such.
> Ville, are you referring to the usual thing with DLLs here (which I mentioned above) or is there something else going on here that I'm not aware of?
The usual thing with DLLs.
>>>> And is it even possible to have different contract handlers set, in dependencies, or do people make that up?
>
>>> I have no idea where such an idea would come from.
>
>
>> That a particular piece of code would like to define how violations in
>> it or in the code it calls are handled? The section "Local Violation
>> Handlers"
>> in P3400?
>
>
> Ville, P3400 is a potential C++29 extension, which is not the topic of discussion here. We're talking about what's in the C++26 working draft, where the contract-violation handler is always global (with the DLL caveat).
I don't know how you determine the topic of the discussion, but when
someone asks "are per-module or per-TU violation handlers a thing?",
and
someone comments "I have no idea where such an idea would come from",
I think it's rather on-topic to point out that such finer-grained
violation handlers have been considered and are on the roadmap for Contracts.
Received on 2025-09-26 07:25:10