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?

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?

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.

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. 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.

Cheers,
Timur

> On 21 Oct 2025, at 10:59, JOSE DANIEL GARCIA SANCHEZ <josedaniel.garcia_at_[hidden]> wrote:
>
> At least we need to answer a question
>
> Deployment experience with particular attention to pre/post in interfaces. By deployment experience a mean real deployment experience (not simulation of that thing) and in different application domains that span multiple companies.
>
> I am not aware of such real deployment experience, I would be glad to see proofs that I am wrong.
>
> I would also like to see what is the real impact of the cases where we have identified emerging UB. I am not meaning a reasoning about it. I am not meaning to be educated by reasoning. I would like to see real experiences in applications with different priorities.
>
> This is a very important feature to make mistakes. I currently think that we are making mistakes (in fact, big mistakes). I really want to be empirically convinced that I am wrong.
>
> Thanks!
> --
> J. Daniel
>
> On Tue, Oct 21, 2025 at 8:43 AM Timur Doumler <cpp_at_[hidden]> wrote:
>>
>>
>>> On 21 Oct 2025, at 07:57, JOSE DANIEL GARCIA SANCHEZ <josedaniel.garcia_at_[hidden] <mailto:josedaniel.garcia_at_[hidden]>> wrote:
>>> For what is worth, some other large features in previous releases of the standard went through a TS process.
>>>
>>> In such cases, the features received substantial modifications before going into the standard.
>>>
>>> That was beneficial both for the feature and for the C++ community.
>>
>> That's fair, but I believe that in all of those other cases, WG21 had not yet reached consensus on a design and there were open design questions that the TS was supposed to answer. For example, for Reflection, it was unclear at the time if we want template metaprogramming-based reflection or constexpr-programming-based reflection. I am
>> not sure about the details for the Modules and Concepts TS as I was not involved in those but I imagine questions of similar magniture existed there.
>>
>> However, in this case, I wonder what the concrete questions are that the TS (or whitepaper, which is essentially the same
>> thing with less ISO bureaucracy attached) is supposed to answer?
>>
>> Please refer to the guidance in P4000 <https://wg21.link/p4000> regarding language TSes:
>> Answer the key question:
>> WHAT ARE we hoping to LEARN through a TS must be clearly specified.
>> WHAT ARE the exit criteria of the TS to IS must be clearly specified.
>> Use TSs for library components.
>> Don’t use TSs for a language feature unless the feature is a mostly self-contained unit.
>> Don’t use a TS simply to delay; it doesn’t simplify later decision making. Have concrete and articulated criteria for completion.
>> So what would be the concrete and articulated criteria for completion here?
>>
>> There are a number of people here who object to the P2900 design that WG21 already had consensus on, and that's fine — we will hear those objections again as required by the NB comment process. But as far as I can see, almost all of the objections are of the shape "this design is not good enough in my opinion because it does/doesn't have property X" but do not offer any concrete criteria or alternative designs that we could actually evaluate in a TS.
>>
>> The notable exception to this is Ville's P3853R0 <https://wg21.link/p3853r0>, which *does* have that concrete suggestion / TS shape: "put both P2900 and P3640 into a White Paper or a Technical Specification". However, the problem with that proposal is that P3640 <https://wg21.link/p3640> already *has* been evaluated by multiple WG21 subgroups and all of them had strong consensus against pursuing this direction any further (poll results here: https://github.com/cplusplus/papers/issues/2277). During those discussions, essentially everything that is being discussed here has already been discussed in quite some detail. Given that no new information has been presented since then, it seems unlikely that reviving P3640 and discussing all of this one more time would lead to a substantially different outcome than last time regarding the design we want in the IS (flexible semantics by default or fixed semantics by default).
>>
>> Cheers,
>> Timur
>>