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