FYI I was completely unaware that SG16 had discussed P1030. Nobody told me.
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.
I should add that the killing off of char input was strongly requested
by Billy. I got the feeling it was a red line for him. I can understand
why, from a MSVC-implementer perspective, and I have witnessed first
hand the brokenness of char input to path on Windows.
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"" strings. "Everyone suffers equally" is a bit of a cold comfort, though, but it's completely understandable why.
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!
The aim is for path_view to be usually no worse than path, nothing more.
If the input is in UTF-8, and the system API requires UTF-16, then you
need to convert, same as for path. Unless you want to push mandatory
#ifdef-ing onto the end user, which I don't think we want.
Right, I think what was lost in the original example upon Tom's reading was that it _always_ converted. That's not the case for path_view: it will only convert if the passed-in encoding does not match the native file system's encoding, and only do such a conversion when necessary. If the user passes in UTF8 on POSIX, no converting will be done.
Finally, I have one more... thing? It'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't need what will probably amount of "Expects: ptr[size] == 0 is true" 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's not exactly impossible: I have received a lovely crop of bug reports from people seeing "std::string_view" overloads in my libraries and passing non-null-terminated strings into them, because that's what string_view promises. Whether or not your wording has an "expects" clause, it's not difficult or hard to imagine substring or other similar pointer + size manipulations to produce hell here.
Then again, this is marked as the path_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.
Sincerely,
JeanHeyd Meneide