On 7/31/19 12:34 PM, Niall Douglas wrote:
>
> 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:

  * https://github.com/sg16-unicode/sg16-meetings#july-31st-2019

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).

Tom.