Date: Tue, 21 Oct 2025 08:43:33 +0200
> 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
> 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
Received on 2025-10-21 06:43:39