This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

3975. Specializations of basic_format_context should not be permitted

Section: 28.5.6.7 [format.context] Status: WP Submitter: Brian Bi Opened: 2023-08-13 Last modified: 2024-04-02

Priority: 3

View all other issues in [format.context].

View all issues with WP status.

Discussion:

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

Previous resolution [SUPERSEDED]:

This wording is relative to N4958.

1. Modify the 28.5.6.7 [format.context] as indicated:

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

   -?- The behavior of a program that adds specializations of basic_format_context is undefined.

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

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

[2023-10-30; Reflector poll]

Set priority to 3 after reflector poll.

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

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

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 28.5.6.7 [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 28.5.6.6 [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.