> 2. On simplicity: My minimal c_str_view was motivated exactly because if we want a lightweight type, avoiding code duplication from string_view is key. One way to achieve this is making it a subtype inheriting from string_view (hiding/override data() if needed, adding c_str() for clearer semantics). Since a null-terminated view is always a valid string_view (but not vice versa), inheritance fits naturally – with no space overhead. Alternatively, keeping it independent with to_string_view() also avoids duplication. Either way seems fine to me.

As Peter pointed out, there has been existing discussion on the
inheritance approach.

Regarding relying on a string_view conversion for everything, that
doesn't really accomplish much. The implementation for
std::cstring_view, as currently proposed, is already incredibly simple
and straightforward (see the beaman project reference implementation
linked in the latest draft and my reference implementation linked in
earlier drafts). Every member function is a one-line wrapper. This is
arguably boilerplate and it's something that will need to be kept
consistent with std::string_view and std::string, but it's not
complexity.

The cost of requiring everything to go through a string_view
conversion is that every use of the type would be cumbersome.
Additionally, you are proposing a string view type with an interface
that doesn't match either std::string or std::string_view. The benefit
is minor to negligible.

Being able to use the same interface as other strings and containers
is important for template metaprogramming. For example, the following
code should work for pretty much every string and string_view type,
both in the standard library and other libraries (boost string view,
folly strings, ...), but it would break with your c_str_view.
```
template<typename StringType>
auto trim_left(const StringType& s) {
    auto it = std::find_if_not(s.begin(), s.end(), ::isspace);
    return s.substr(std::distance(s.begin(), it));
}
```

I would like to humbly suggest that your implementation isn't simpler,
it's incomplete.

Cheers,
Jeremy

On Mon, Feb 2, 2026 at 4:08 AM Peter Bindels via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Hi,
>
> On Mon, Feb 2, 2026 at 9:00 AM FPE <foxofice.fpe_at_[hidden]> wrote:
>>
>> Thank you all for the continued feedback – especially Jan Schultke for the detailed comparisons, Thiago Macieira for raising the important security concerns, and Ville Voutilainen for the broader perspective!
>>
>> I completely agree that solving this pain point (safe, efficient interop with C/WinAPI) is more important than whose design wins. I'd love to see std::cstring_view (or equivalent) in the standard as soon as possible, ideally for C++29 – regardless of whether it builds on my ideas or the current P3655R3. The demand is clearly there.
>>
>> A few thoughts in response:
>>
>> 1. Progress: What has been the main blocker for P3655/cstring_view so far? From the revisions, it seems more about design consensus (naming, invariants, etc.) than implementation complexity – is that accurate?
>
>
> P3655 was seen in Sofia last year summer. It was updated in case there was time to see it in Kona (november), but all time was reserved for C++26 proposals instead. It is on the queue for Croydon (March) but that hasn't happened yet, and it will necessarily take second seat to C++26 changes. There is nothing blocking it except for the time to be discussed.
>
>>
>> 2. On simplicity: My minimal c_str_view was motivated exactly because if we want a lightweight type, avoiding code duplication from string_view is key. One way to achieve this is making it a subtype inheriting from string_view (hiding/override data() if needed, adding c_str() for clearer semantics). Since a null-terminated view is always a valid string_view (but not vice versa), inheritance fits naturally – with no space overhead. Alternatively, keeping it independent with to_string_view() also avoids duplication. Either way seems fine to me.
>
>
> P3655 has the discussion on this in §6.1.
>
>>
>> 3. On exceptions/checks: I still believe a one-size-fits-all noexcept/UB approach might not suit everyone. Some projects have zero tolerance for UB and prefer fail-fast (e.g., via exceptions or asserts in debug). Perhaps an optional macro (e.g., HAVE_C_STR_VIEW_EXCEPTION, default off) or contracts could accommodate this without forcing it on performance-critical code?
>
>
> P3655 specifies the checks as preconditions and postconditions. How your vendor implements this is entirely up to them. I would suggest using contracts.
>
>>
>> 4. On Thiago Macieira's security concerns (embedded nulls): Great points – these are real risks in untrusted input scenarios. However, going back to string_view's original goals: it accelerates code by trusting input (avoiding repeated strlen) and consolidating (ptr, len) into one object.
>
>
> P3655 has its discussion on this in §6.4. It mentions among other things:
>
> > We do not propose to forbid embedded NUL bytes, keeping the type aligned with string and string_view. The existence of embedded NUL bytes is a separate topic and should be handled in a separate paper. Note that even the C++ standard itself has embedded NULs in some of its string values, for example in [facet.numpunct.virtuals]/3 do_grouping.
>
> Best regards,
> Peter Bindels
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals