On Tue, 21 Oct 2025 at 12:20, Timur Doumler <cpp_at_[hidden]> wrote:
>
> I understand the calls for real deployment experience, but I don't understand how is a Contracts TS or whitepaper would help us get that?

Well, see, it's actually less about what the ship vehicle
semi-magically (I'm intentionally joking here) does. It's about what
chance anyone
has to experiment with the feature before we nail it into an IS.

Let's face it, it's excruciatingly difficult and therefore unlikely
for so-called third parties to experiment with what we have right now.
You would
need to build a fork-branch compiler, and then deploy that and then do
the actual experimentation. That by nature shuts out quite a bunch of
users.

That situation will change in non-distant future, when the work is
upstreamed and later released in an actual shipping version, but the
upstreaming
is already a big step forward because it at least gives a chance for
people to experiment with a compiler installed from a snapshot
package.

> Can you name a language feature where we successfully gained the kind of real deployment experience you are asking for by releasing a TS, that we would not have gained without the TS?

See above. We didn't gain that expeience BY releasing a TS, we gained
it by NOT putting the unbaked feature into an IS and hoping it's
perfect without deployment. And yes, we can, see coroutines. We got
significant deployment experience -based feedback that shaped
the final design. We got such deployment experience for Concepts too,
before they were standardized. Various people debate how
much deployment experience we had and on what when it comes to
Modules, but the design of that language feature was heavily
influenced by deployment experience.

Look at function contract assertions. What feedback do we have, from
people who have actually used them, in the C++ form,
on C++ projects? (The question is rhetoric, you don't have to answer
it. Think about it. Think whether the answer is good, and
after you've done that, please start working ASAP on *FIXING* that
problem, not debating on whether it's a problem that needs to be
addressed
before deadline X or before adoption into an IS. That problem does
need to be fixed, and we can't start too early.)

What feedback could we get? Some, at least.

> Can you name any software companies that would be willing to deploy code in real-world production that makes use of a not-yet-standardised TS/whitepaper language feature *on interfaces*? I can't.

There is no ask that it needs to be "in production" or whichever
attributes you might perhaps unknowingly add there, like, as a
straight up
strawcreature argument, "in your mission-critical system that cannot
fail or your company goes bust". We are not asking for that, none of
the people asking for deployment experience are asking for that.

What we are asking is that we give users a CHANCE to get and report
that deployment experience. If we go straight to an IS, we don't give
them
that chance. Any prophecy of "we won't get any deployment experience"
becomes self-fulfilling.

And *THAT* is something I object to harder than anything else. We know
how to give users such a chance. If we deliberately choose not
to, we are just doing a deliberately bad job, and that's the end of that.

And who knows, by giving that chance to users, and maybe sending out
an open invitation to pretty please provide such feedback, we might
even get it. We have people who could help facilitate that; as my
paper says, we have such people in a couple of Universities. We have
such
people in some companies, among our members. Suggesting that we won't
get it because we didn't get it before is admitting defeat,
and not actually looking at the earlier problems. Maybe getting that
feedback isn't impossible, or even all that hard, but we just really
sucked, as a committee, at getting it? Maybe we could learn to do better?


> I understand why it would be a good thing to have that, but I don't think that's a reasonable expectation for a new language feature, and I don't remember this high bar ever having been applied for any other language feature we have standardised in the past.

The bar for Concepts was sky-high, and miles above anything we are
asking here. YMMV and all that, but I do not exactly find arguments
that something is treated to some extent unfairly, or differently,
very convincing.

After all, if nothing can ever have different requirements than things
that came before it, then nothing in our technical can ever change,
and that includes that nothing can ever improve. (Just pre-emptively:
Please, you don't need to say that you're not suggesting that. I am
not suggesting
that you did. :) ) I'm making an observation, a point about the
conceptual arguments, properties thereof, and concerns/consequences
thereof,
of such arguments. And you're not the first nor the only people who've
made such arguments. So did almost all the proponents of Concepts. :)

>Realistically, the only way to get that real deployment experience across different domains and companies is to put an initial feature set into the *IS* and have it ship in major compiler releases — otherwise those different domains and companies simply won't use the feature in production.

We have prior evidence that disagrees with that. And if we do that,
then there's a whole category of things we can't change based on
whatever
feedback we get, things that we would be too concerned to change due
to such changes being breaking.

This is why I have said that such a trial balloon is made of lead. It
can't fly. It's not *ACTUALLY* open for change based on feedback. It
pre-emptively
closes the door for some kinds of feedback we might get. Or might not.
But regardless of whether we could get such feedback, it does close
that door.