Thank you all for the ongoing discussion – it's great to see so many
thoughtful perspectives!

I wanted to express strong agreement with Arthur O'Dwyer's point in his
recent message (16959.php). Since std::string and std::string_view both
allow embedded nulls (e.g., constructing a string_view from a std::string
containing "\0" includes the full length beyond the null),
std::cstring_view should behave consistently for the same reasons.
Inconsistency here would be seriously misleading to users who expect the
"string" family to align.

If cstring_view were to disallow embedded nulls or stop at the first one,
it would break seamless interoperability with the rest of the string view
ecosystem – member functions wouldn't match, conversions would be
error-prone, and switching between types would require extra care or
copies. In that case, it might be better to avoid the "string" naming
entirely (perhaps something like txt_view or similar) or even just use raw
char* for strict C semantics.

While I understand the concerns raised by Thiago Macieira and Jason
McKesson about prioritizing pure C semantics (stopping at the first null
for safety/reliability with C APIs), I believe the risks of breaking
consistency with string_view outweigh that in most cases – especially since
string_view already trusts user input in similar ways. Keeping alignment
makes the type much more usable in modern C++ code without surprising
developers.

Thanks again,

Best,
FPE(foxofice)

Jeremy Rifkin <jeremy_at_[hidden]> 于2026年2月3日周二 04:10写道：

> > 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
>