On 03/07/2019 22:52, Lyberta wrote:
> Ok, some more feedback:
>
> path_view(const std::basic_string<std::byte> &v) noexcept;
>
> std::basic_string<std::byte> doesn't exist.

Bah. That's a mistake. I had intended to write std::span<std::byte>.
Thanks for the catch, it's already fixed in R3.

> constexpr path_view(const std::byte *v, size_t len) noexcept;
>
> It says: "The character after the end of the view must be legal to read."
>
> What is character? Is it back to "native type"? Does it means it require
> 2 subsequent bytes be legal to read on Windows?

R3 now says:

  \warning `sizeof(filesystem::path::value_type)` bytes after the end
  of the view must be legal to read.

Is this acceptable?

> All constructors taking pointer and size and std::basic_string_view look
> like a big footgun to me. I think it is better to redesign type system
> in order to not let users shoot themselves in the foot so easily.

I don't personally think that implicit construction of a view from other
views is problematic. You've already loaded and pointed that footgun.

The pointer and size constructors are the same as those for any other
string-like view. Not having them would be surprising.

> Maybe reduce the amount of constructors by taking std::ContiguousRange.

I didn't choose that because I worried that it would lead to inadvertent
unsafety. For example, std::vector<char8_t> or span<char8_t> would work.

If LEWG feel it safe, then okay.

> Until we put more restrictions on CHAR_BIT, I think c_str::length should
> be std::uint_least16_t.

I was being a little bold here: struct c_str exactly matches
UNICODE_STRING on Windows, and thus can be fed directly to Windows
without copying. I would not be surprised at all if LEWG requested a
size_t here, along with a much smaller non-allocating stack buffer, and
that would be fine.

Thanks for the bug catches. Very useful.

Niall