What are the constraints on the template parameter of basic_format_arg?
Richard Smith

Created on 2019-08-01.00:00:00 last changed 7 months ago


Date: 2019-08-17.10:19:50

Proposed resolution:

This wording is relative to N4830.

  1. Modify [format.arg] as indicated:

    template<class T> explicit basic_format_arg(const T& v) noexcept;

    -4- Constraints: The template specialization

    typename Context::template formatter_type<T>

    is an enabled specialization of formattermeets the Formatter requirements ([format.formatter]). The extent to which an implementation determines that the specialization is enabledmeets the Formatter requirements is unspecified, except that as a minimum the expression

    typename Context::template formatter_type<T>()
      .format(declval<const T&>(), declval<Context&>())

    shall be well-formed when treated as an unevaluated operand.

Date: 2019-08-17.00:00:00

[ 2019-08-17 Issue Prioritization ]

Status to Tentatively Ready and priority to 0 after six positive votes on the reflector.

Date: 2019-08-01.00:00:00

In P0645R10 20.?.5.1/ we find:

Constraints: typename Context::template formatter_type<T> is enabled.

… which doesn't mean anything, because that is an arbitrary type. Presumably the intent is that that type will always be a specialization of formatter, but there appear to be no constraints whatsoever on the Context template parameter, so there seems to be no requirement that that is the case.

Should basic_format_arg place some constraints on its Context template parameter? E.g., should it be required to be a specialization of basic_format_context?

Victor Zverovich:

The intent here is to allow different context types provide their own formatter extension types. The default formatter context and extension are basic_format_context and formatter respectively, but it's possible to have other. For example, in the fmt library there is a formatter context that supports printf formatting for legacy code. It cannot use the default formatter specializations because of the different syntax (%... vs {...}).

Richard Smith:

In either case, the specification here seems to be missing the rules for what is a valid Context parameter.

I'm happy to editorially change "is enabled" to "is an enabled specialization of formatter", since there's nothing else that this could mean, but we still need a wording fix for the broader issue here. Here's what I have so far for this wording:

Constraints: The template specialization typename Context::template formatter_type<T> is an enabled specialization of formatter ([formatter.requirements]).

Tim Song:

I think what we actually want here is "typename Context::template formatter_type<T> meets the Formatter requirements".

Date User Action Args
2019-11-19 14:48:30adminsetstatus: voting -> wp
2019-10-07 02:48:00adminsetstatus: ready -> voting
2019-08-17 10:19:50adminsetmessages: + msg10554
2019-08-17 10:19:50adminsetstatus: new -> ready
2019-08-03 18:53:28adminsetmessages: + msg10538
2019-08-01 00:00:00admincreate