On Fri, 26 Sept 2025 at 11:05, Timur Doumler <cpp_at_[hidden]> wrote:
>
> Hi Ville,
>
> > On 26 Sep 2025, at 10:57, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
> > That doesn't require "new technology" either, jeesh. We could add a
> > library symbol that reveals the evaluation semantic chosen for that
> > library (which is
> > no different from having a version symbol in a library), or we could
> > generate forcibly-non-inlined function calls that you can scan for in
> > the library.
> > Then you can just grep the result of nm to find out the contract
> > evaluation semantic for a particular library binary, and I don't think
> > that counts as "new technology".
>
> Right, but if you want this to be user-friendly, you still have to teach the linker to do all this automatically.

No, I don't. I can do the check in a build system and teach it to do
it automatically. I can make my code
check for the expected semantic in the code it invokes. I don't have
to teach the linker anything, that's
not necessary, and isn't the best way to approach the problem.

>
> >> Are we good now?
> >
> > When this committee's members actually prototype their ideas and
> > gather real implementation and deployment experience for their grand
> > ideas, yes.
>
> We have implementation experience for the approach of compiling with a fixed semantic, which I think is what most people will end up doing as that's how assertions work today.
>
> We cannot reasonably gather significant real-world deployment experience with a new language feature until it is part of an ISO C++ Standard and ships with the regular releases of major compilers. Approximately nobody adopts experimental not-yet-standardised features for real-world use at scale. Requiring broad deployment experience with a language feature in advance of standardisation creates a chicken-and-egg problem: applied consistently, it would have prevented most language features of modern C++ — often far more complex than contract assertions — from ever being realised.

Nice shpiel. It misses the fact that many of those language features
had implementation and deployment experience far beyond what contracts
have, well before they were standardized, and that provides rather
contrary evidence to the claim that "approximately nobody adopts
experimental features".
Then there's the various significants and atscales, which aren't
necessarily what we're even talking about when desperately requesting
features
to have deployment experience before they are adopted. Contracts have
next to none, and claims like yours above don't make that a non-issue.