Skip to content

US 38-098 22.14.6.4p1 [format.string.escaped] Escaping for debugging and logging #515

@wg21bot

Description

@wg21bot

The subject subclause describes how characters or strings are "escaped" to be formatted more suitably "for debugging or for logging".

The actual suitability for debugging or for logging depends on the needs of the application, and there is a conflict between formatting for human readability of the textual content and formatting for clarity and fidelity of encoding nuances. Indeed, for the latter, there can still be (for stateful encodings) a conflict between formatting for human visual inspection versus formatting for machine consumption of the output sequence as a C++ string/character literal.

The current design introduces extensions to the API and to the format string syntax that assume that there is one specific default that should be chosen "for debugging or for logging". The reasoning behind the chosen default and the extensibility of the current design does not appear to be sufficiently explored.

Note 1:
An example, for Unicode encodings, of a choice between prioritizing between human readability of the textual content and visual clarity of encoding nuances is in the treatment of characters having Unicode property Grapheme_Extend=Yes. The current design favors visual clarity of encoding nuances by outputing such characters as escape sequences.

Note 2:
For stateful encodings, the lack of return to the initial shift state at the end of the sequence cannot be represented using a C++ string/character literal unless if a prior shift sequence from the initial shift state is rendered via escape sequence(s). It is not clear that scanning forward is generally always an option (nor is it clear that doing so is desirable).

Proposed change:

Narrow the purported scope and affirm the design choices of the default behavior:
Modify "logging" to "technical logging" and spell out the priorities in order in the description (this has the benefit of clearly communicating intention and providing guidance for implementation choices).
1. The output is intended to be a C++ string/character literal that reproduces the encoded sequence. (This seems to be taken for granted and not made explicit in the current draft.)
2. Prefer visually distinguishing between different methods of encoding "equivalent" textual content.

Make any adjustments necessary to the API or the format string syntax associated with "escaped" strings to allow for future additions for alternative escaping.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Status

    Tentatively Ready

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions