LWG4070 Transcoding by std::formatter<std::filesystem::path>

[jwakely]

https://cplusplus.github.io/LWG/issue4070

LWG would like SG16 to discuss this issue please.

[tahonermann]

SG16 discussed this issue during its 2024-06-12 meeting. No polls were taken. SG16 will review again in the new year.

[tahonermann]

Now that I've finally published a meeting summary for the 2024-06-12 SG16 meeting, I can detail the next steps for resolving this issue.

The "and not converting from wchar_t to UTF-8" wording added in the index of implementation-defined behavior by the current proposed resolution should be changed to "and the literal encoding is not UTF-8".

It was noted that "the literal encoding" is ambiguous in both the normative wording in [fs.path.fmtr.funcs]p5 and in the new wording quoted above. In both cases, the intent is to refer to the "ordinary literal encoding". However, some SG16 participants were reluctant to include a drive-by fix with the proposed resolution for this issue since the ambiguous literal encoding reference is a pre-existing and separable issue. Those same SG16 participants were more concerned that the same wording was used in both [fs.path.fmtr.funcs]p5 and in the corresponding entry of the implementation-defined behavior index. I would defer to the LWG chair to decide whether to address this as an additional related clarification with this change or as a separate editorial or LWG issue.

@jwakely, can you please update the proposed resolution for this issue? The minimal change is to replace "and not converting from wchar_t to UTF-8" with "and the literal encoding is not UTF-8". The optional change is to insert "ordinary" before "literal encoding" as well. Once that is done, I'll have SG16 confirm they are content with the new proposed resolution.

[Dani-Hub]

I have made the suggested P/R change (including the optional change), see LWG 4070. Since SG16 wishes to rediscuss I have not changed the current SG16 status of the issue.

[tahonermann]

Thanks @Dani-Hub. Per the SG16 notes, if the modification to the entry in the index of implementation-defined behavior states "ordinary literal encoding", then the existing use of "literal encoding" in [fs.path.fmtr.funcs] should also be changed to "ordinary literal encoding" for consistency. Alternatively, drop "ordinary" in the modified wording and we'll resolve the literal encoding ambiguity via a separate issue.

[Dani-Hub]

The optional wording suggestion has been completed now (It may require some further minutes to make the LWG pages refresh).

[tahonermann]

That looks great @Dani-Hub, thank you!