No, just call a function (from a single thread) breaks it:   f(ts.substr(4, 7), ts.substr(6, 2));     https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3655r3.html#Member-functions-on--string_view--that-return-a--string_view-   The P3655R3 paper solves substr as elegant as it can get.     On alternative could be to have a non-contiguous type inserting a NUL character at the end, when using the [] operator. However such a type's memory layout would not be very compatible with C APIs.     -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 02.02.2026 10:36 Betreff:Re: [std-proposals] [Idea] Null-terminated string view (c_str_view / c_wstr_view) – a simpler alternative/complement to zstring_view An:std-proposals_at_[hidden]; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; On Monday, February 2, 2026, Jason McKesson wrote: The question of whether `substr` should be a `const` function is a "yes/no" question. One of those answers is correct. Your code uses the other answer.   I pondered for a moment when writing that function whether 'substr' should be const or not.  At first I was thinking it would be good if a TermString would never be const, as though we were able to write a constructor as follows:     MyClass::MyClass(void) const(false) { . . . }  As TermString is non-owning, really all of its members can be const (and they are). But then I though hmmmm... maybe a non-const TermString can alter the referred buffer, and a const TermString cannot alter the referred buffer. Given that substr can return an object that can be used to alter the underlying buffer, I figured make it non-const. I hadn't put a huge deal of thought into it though.  By the way I realise the destructor of a const TermString can alter the buffer but really it's only restoring it back to the way it was.  When I decide to mark a member function as either const or non-const, I take into account more than just the editing of the member variables, I also consider a few other things.  Anyway we are in disagreement Jason about whether my TermString class is really a bad idea. So long as only one thread is using the referred buffer, it's perfectly fine to pluck the null terminator and move it around for a moment, then put it back where it was. I would definitely use this strategy to optimise a program that extensively uses long null-terminated strings that frequently need to be substr'ed.   -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals