<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 3, 2019, 17:11 Niall Douglas &lt;<a href="mailto:s_sourceforge@nedprod.com" target="_blank" rel="noreferrer">s_sourceforge@nedprod.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">To explain the dependency, path_view really wants to avoid ever copying<br>
memory.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">The paper shows</div><div dir="auto">bool _buffer_needs_freeing;<br></div><div dir="auto"><br></div><div dir="auto">I find it surprising that a type name foo_view is more like a copy-on-write type than a pure view.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> means we cannot use the same API as filesystem::path. So,<br>
if on Windows you write:<br>
<br>
path_view(u16&quot;c:/some/path&quot;);<br>
<br>
... then the literal string gets passed directly through to the wide<br>
character Windows syscalls, uncopied. If on POSIX, it would undergo a<br>
just-in-time downconversion to UTF-8.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">If whether a copy happens is platform-dependent, it’s pretty unfortunate that this paper and the file system API don’t adopt WTF-8 and putting the conversion on the Windows side. See below.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This works by path_view inspecting the char literal passed to it for its<br>
type. It refuses to accept `char`, it will only accept byte [1],<br>
char8_t, char16_t and char32_t. In other words, you must explicitly<br>
specify the UTF encoding for path view input.<br>
<br>
Is SG16 happy for LEWG to review P1030?<br>
<br>
Niall<br>
<br>
[1]: Raw bytes are accepted because most filesystems will actually<br>
accept raw binary bytes (minus a few reserved values such as &#39;/&#39; or 0)<br>
as path identifiers without issue. There is no interpretation done based<br>
on Unicode. Thus, not supporting raw bytes makes many valid filenames<br>
impossible to work with.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">To evaluate this, it would be important to state what the semantics for bytes are on Windows. Interpreting them according to the “ANSI” code page of the process would be traditional but does not allow addressing all files and goes directly against the motivation stated.</div><div dir="auto"><br></div><div dir="auto">I encourage the committee to look at supporting WTF-8 (<a href="https://simonsapin.github.io/wtf-8/">https://simonsapin.github.io/wtf-8/</a>) as an 8-bit-code-unit encoding that</div><div dir="auto">1) Allows addressing all NT file paths</div><div dir="auto">2) Is equivalent to UTF-8 for those NT file paths that have a textual interpretation.</div><div dir="auto"><br></div><div dir="auto">This allows for portable code (where the platform-dependent conversion goes on the Windows side unlike in the example above). On POSIX-like platforms, you’d instead use a sequence of bytes to address all file paths and if the path happens to be valid UTF-8, the path has a textual interpretation. To enable even more portable application code, you’d make the file system library swap \ and / on Windows similar to how : and / are swapped to expose HFS+ in a POSIX-compatible way.</div><div dir="auto"><br></div><div dir="auto">(The Rust file system API uses WTF-8 on Windows enabling portable application layer code that can address all file paths in both Windows and POSIX with cheap conversion to/from UTF-8 strings.)</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>