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