A different conceptual approach could be: Instead of working from types to prevent those bugs (nullptr or unrelated begin/end) to specify from the contents of the pointers and let the compiler/optimizer try to find the bugs in practice for those cases.   -> add requirements or pre-conditions to the declaration (in this case of the string_view constructor) that a compiler would recognize in those cases, where a literal is given in a wrong way or a simple to resolve non-literal is given in a wrong way. E.g. some pre-condition: ptr != nullptr && ptr != NULL Or: belong_to_same_allocation(ptr_begin, ptr_end) If those pre-conditions or requirements are analyzed on a best-effort base than they could be recognized at compile-time for the trivial cases, even slightly beyond directly passing literals.   The argument above is just a general direction, not a worked out solution in C++ standard language. And I am not sure, if it can be somehow made to work with the contracts feature or what would be needed.   -----Ursprüngliche Nachricht----- Von:Andrey Semashev via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mi 28.10.2026 14:29 Betreff:Re: [std-proposals] Proposal: Disallow string(_view) construction from two literals An:std-proposals_at_[hidden]; CC:Andrey Semashev <andrey.semashev_at_[hidden]>; On 28 Oct 2026 15:19, Johannes Kalmbach via Std-Proposals wrote: > Hi, > The following snippet compiles, but invokes UB, because overload > resolution treats the decayed pointers to the two string literals as > begin an end of the string: > > `std::string s{"undefined", "behavior"}` > > I would propose disallowing this antipattern, similar to P2166 disallows > string construction from `nullptr`.  I feel like this, and the deleted constructor from nullptr, are pretty much useless in practice. The nullptr one disallows construction when the user explicitly specifies nullptr as the argument. Noone does that in practice. The only reasonable case where that could happen is when the argument is forwarded by the caller from an unconstrained template argument, but then you have to wonder if the correct fix would be to constrain the caller. The deleted constructor does not prevent a null pointer to character type from being passed, which is the real cause of bugs of this kind most of the time. Same with the proposed two-literals constructor - noone writes that code, and again it doesn't help with real cases, when the caller accidentally passes two unrelated pointers to characters. And while, yes, the nullptr one got accepted, I do not think this alone is a good enough motivation to add more similar deleted constructors. PS: No, I'm not proposing to add runtime checks for null or that input iterators are reachable to prevent user mistakes. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals