<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 7/31/19 12:34 PM, Niall Douglas
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:360b3930-032a-be65-f921-7b34cefd7931@nedprod.com"><br>
      <pre class="moz-quote-pre" wrap="">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.</pre>
    </blockquote>
    <p>Good, thanks, I'm glad to hear that.</p>
    <p>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:</p>
    <ul>
      <li><a class="moz-txt-link-freetext" href="https://github.com/sg16-unicode/sg16-meetings#july-31st-2019">https://github.com/sg16-unicode/sg16-meetings#july-31st-2019</a></li>
    </ul>
    <p>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).</p>
    <p>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).<br>
    </p>
    <p>Tom.<br>
    </p>
  </body>
</html>