<div dir="ltr"><div>Dear Niall Douglas,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 3, 2019 at 1:11 PM Niall Douglas &lt;<a href="mailto:s_sourceforge@nedprod.com">s_sourceforge@nedprod.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
FYI I was completely unaware that SG16 had discussed P1030. Nobody told me.<br></blockquote><div><br></div><div>      Apologies, that was my failing: I think I had only briefly mentioned it during my first meeting Standards Meeting after I first met you in Rapperswil, Switzerland, but I likely should have delivered the feedback VIA e-mail rather than a brief gloss over in person in the most timid of fashions.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
I should add that the killing off of char input was strongly requested<br>
by Billy. I got the feeling it was a red line for him. I can understand<br>
why, from a MSVC-implementer perspective, and I have witnessed first<br>
hand the brokenness of char input to path on Windows.<span class="gmail-im"><br></span>

</div></blockquote><div><br></div><div>     I am very glad that `char` is not included here. My only potential concern is that Linux-exclusive users will cry out. But then again, so will MSVC users with L&quot;&quot; strings. &quot;Everyone suffers equally&quot; is a bit of a cold comfort, though, but it&#39;s completely understandable why.<br><br></div><div>     If my Unicode work is anywhere close to mildly successful, it might make it possible to specify char and wchar_t overloads as conversions. But that can be added at a much later date with no breakage to the proposal as it is, which is great! Yay!<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
The aim is for path_view to be usually no worse than path, nothing more.<br>
If the input is in UTF-8, and the system API requires UTF-16, then you<br>
need to convert, same as for path. Unless you want to push mandatory<br>
#ifdef-ing onto the end user, which I don&#39;t think we want.

</div></blockquote><div><br></div><div>     Right, I think what was lost in the original example upon Tom&#39;s reading was that it _always_ converted. That&#39;s not the case for path_view: it will only convert if the passed-in encoding does not match the native file system&#39;s encoding, and only do such a conversion when necessary. If the user passes in UTF8 on POSIX, no converting will be done.<br><br></div><div>     Finally, I have one more... thing? It&#39;s not really a concern or a nit with the paper, just a bit of sadness: had we standardized a c_string_view of some form, we wouldn&#39;t need what will probably amount of &quot;<i>Expects: </i>ptr[size] == 0 is true&quot; on all the specifications on the constructors for the string view / charX + pointer overloads. I agree with the reasoning in the paper that there is rarely a case where users expect that to be the case, but it&#39;s not exactly impossible: I have received a lovely crop of bug reports from people seeing &quot;std::string_view&quot; overloads in my libraries and passing non-null-terminated strings into them, because that&#39;s what string_view promises. Whether or not your wording has an &quot;expects&quot; clause, it&#39;s not difficult or hard to imagine substring or other similar pointer + size manipulations to produce hell here.<br><br></div><div>      Then again, this is marked as the <i>path</i>_view type. Maybe that will be enough visual indication to the user they should think carefully and not just toss in random substrings. I certainly hope it is.<br></div><div><br></div><div>Sincerely,<br></div><div>JeanHeyd Meneide</div></div></div>