FYI Tom you've gained back your `char` constructor, as requested. There is also a wchar_t constructor, because if you have one, you can't avoid the other. On Windows, this performs the hideous locale-dependent ANSI to wchar_t conversion which mangles the input as per Windows ANSI rules.
Good, thanks, I'm glad to hear that.
SG16 ended up rehashing much of the discussion we had in Cologne about path_view and the std::byte, char, and wchar_t interfaces in our last telecon. That wasn't planned (otherwise I would have invited you), but it turned out to be a productive discussion. Some minds were changed. A summary is available at:
The discussion highlighted what may have been a misunderstanding on my part. I had been viewing the std::byte interface as intending to allow programmers to explicitly specify path names that would be stored exactly with the name provided on the filesystem. Others had what, to me, is a much more reasonable perspective; that the std::byte interface exists as a means to pass back to the OS a path that was previously provided by the OS (as opposed to something arbitrary constructed by a programmer). In other words, the std::byte interface accepts a pointer to the underlying representation of an opaque structure (e.g., a sequence of bytes on Linux, a sequence of wchar_t on Windows).
If this perspective better aligns with your intents, then I'm
somewhat more on board with it, though I think std::byte is too
generic an abstraction. What about defining the interface in term
of a `raw_path[_view]` type that is an opaque implementation
defined type? I think this would help to avoid incorrect use or
abuse of the std::byte interface, particularly on systems where
path names are just a sequence of bytes. It might make sense for
the `raw_path[_view]` type to be constructible from simple inputs
(e.g., sequences of `char` on Linux and `wchar_t` on Windows).