Date: Thu, 04 Jul 2019 16:23:00 +0000
Niall Douglas:
> R3 now says:
>
> \warning `sizeof(filesystem::path::value_type)` bytes after the end
> of the view must be legal to read.
>
> Is this acceptable?
Yes.
> 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.
I think the problem is that you require the element past the end of
range to be readable. That goes against usual ranges invariants. I think
the logic for checking null terminator should be checking last element
of the range, like operator[](size() - 1) for non empty range. That way
users of ranges get the default behavior and no footgun is at play.
>> 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.
Why is std::vector and std::span are unsafe? Because they don't allow
operator[](size())? This is fixed by previous point.
I think NUL-terminated strings are a big mistake of C and newer Unicode
library shouldn't use them. std::basic_string already breaks invariants
by allowing embedded NULs.
I know that it will take a while for operating systems to stop using NUL
terminated strings but WebAssemply System Interface already fixed that
by using pointer and size. I expect all future OSes not to use
NUL-terminated strings.
> R3 now says:
>
> \warning `sizeof(filesystem::path::value_type)` bytes after the end
> of the view must be legal to read.
>
> Is this acceptable?
Yes.
> 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.
I think the problem is that you require the element past the end of
range to be readable. That goes against usual ranges invariants. I think
the logic for checking null terminator should be checking last element
of the range, like operator[](size() - 1) for non empty range. That way
users of ranges get the default behavior and no footgun is at play.
>> 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.
Why is std::vector and std::span are unsafe? Because they don't allow
operator[](size())? This is fixed by previous point.
I think NUL-terminated strings are a big mistake of C and newer Unicode
library shouldn't use them. std::basic_string already breaks invariants
by allowing embedded NULs.
I know that it will take a while for operating systems to stop using NUL
terminated strings but WebAssemply System Interface already fixed that
by using pointer and size. I expect all future OSes not to use
NUL-terminated strings.
Received on 2019-07-04 18:24:07