Proposed resolution:

This wording is relative to N4958.

1. Modify [formatter.requirements], Table 73, BasicFormatter requirements [tab:formatter.basic] as indicated:

   Table 73: BasicFormatter requirements [tab:formatter.basic]

   Expression	Return type	Requirement
   g.parse(pc)	PC::iterator	Parses format-spec ([format.string]) for type T in the range [pc.begin(), pc.end()) until the first unmatched character. Throws format_error unless the whole range is parsed or the unmatched character is }. [Note 1: This allows formatters to emit meaningful error messages. — end note] Stores the parsed format specifiers in *this and returns an iterator past the end of the parsed range. The expression shall be a core constant expression if g, pc.begin(), pc.end(), and lvalue-to-rvalue conversion for each element in [pc.begin(), pc.end()) are core constant expressions, and no exception is thrown.
   …

[ 2023-10-30; Reflector poll ]

Set priority to 3 after reflector poll. "Should be OK to provide a non-constexpr parse if you only use it with std::vformat and not std::format." "Only the std::formatter specializations in the standard library should be required to have constexpr parse." "No need to require this, but a note with this text explaining when a call to parse can be a constant expression might be nice."

Format strings need to be checkable at compile-time since P2216R3. In order to check a compile-time format string, the parse functions of the formatters need to be called. However, currently there is seemingly no requirement for the parse function to be constexpr, and hence whether a format string is correct for formatted types may be not well-defined at compile-time.