Proposed resolution:

This wording is relative to N4958.

[Drafting note: The suggested wording form is borrowed from exactly the same wording form used for allocator_traits.]

1. Modify [format.context] as indicated:

   -1- An instance of basic_format_context holds formatting state consisting of the formatting arguments and the output iterator.

   -?- If a program declares an explicit or partial specialization of basic_format_context, the program is ill-formed, no diagnostic required.

   -2- Out shall model output_iterator<const charT&>.

2. Modify [format.parse.ctx] as indicated:

   -1- An instance of basic_format_parse_context holds the format string parsing state consisting of the format string range being parsed and the argument counter for automatic indexing.

   -?- If a program declares an explicit or partial specialization of basic_format_parse_context, the program is ill-formed, no diagnostic required.

[ Tokyo 2024-03-23; Status changed: Voting → WP. ]

[ Kona 2023-11-07; move to Ready ]

[ 2023-10-30; Reflector poll ]

Set priority to 3 after reflector poll.

[ 2023-09-23; Daniel comments and provides improved wording ]

During the reflector discussion, Dietmar pointed out that the constraint can in principle be checked statically (e.g. when the Library creates or refers to an instantiation of basic_format_context), so we can reduce the rather draconian consequence of "undefined behaviour" to "ill-formed, no diagnostics required". Furthermore, the new wording also adds the same constraint to basic_format_parse_context as suggested by Tim. This is needed, since only one public constructor is specified, but that specification does not allow to construct an object a non-zero num_args_ or with the type information necessary for the check_dynamic_spec* functions, so the library has an unspecified way to realize this.

The current wording allows users to specialize std::basic_format_context. However, an implementation is not likely to accept a program that uses the library in a way that would instantiate such a specialization, because [format.context] does not provide a complete description of the interface that such a specialization would need to have (e.g., it does not provide a means to initialize the exposition-only args_ member). Since the library was not designed to be able to work with user specializations of std::basic_format_context, declaring such specializations should be explicitly disallowed.