LWG3840 filesystem::u8path should be undeprecated

[jwakely]

Undeprecating this API is evolutionary and so requires LEWG input:

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

[brycelelbach]

Has SG16 seen this? @tahonermann?

[tahonermann]

Has SG16 seen this?

@brycelelbach, no, but I don't think deprecation is really a SG16 concern. However, if you would like SG16 to offer a recommendation, I'll be happy to schedule a discussion there.

[brycelelbach]

2023-01-10 Library Evolution Telecon

LWG3840: filesystem::u8path should be undeprecated

2023-01-10 Library Evolution Telecon Minutes

Chair: Bryce Adelstein Lelbach

Minute Taker: Ben Craig

Start: 2023-01-10 12:04 Eastern

POLL: Send the proposed resolution to LWG3840 (filesystem::u8path should be undeprecated) to Library for C++23, to be confirmed by a Library Evolution electronic poll.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
0	3	2	5	1

Attendance: 13

# of Authors: 0

Author Position: N/A

Outcome: No consensus.

End: 12:16

Summary

This issue argues that we should undeprecate filesystem::u8path. We discussed this suggestion, but there was little appetite for doing so.

filesystem::u8path is the only standard library interface that requires data provided in char-based storage to be encoded in a different character encoding than the execution character set or the encoding used for character and string literals.
For those that intentionally store UTF-8 data in char-based storage and would prefer not to use a deprecated interface, an equivalent to filesystem::u8path can be implemented in a few lines of code:

inline auto myu8path(const char* s) {
  std::u8string u8s(s, s+std::strlen(s));
  return std::filesystem::path(u8s);
}

The Unicode and Text Study Group is evaluating approaches to enable restricted aliasing support for char8_t such that data in char-based storage could be passed to a char8_t-based interface without having to perform a copy as in the example code above. P2626 is one such proposal.

Next Steps

Close the issue.