Yeah, at this point I feel like the entire proposal is an empty filler.

On Wed, Oct 28, 2026 at 6:29 PM Andrey Semashev via Std-Proposals <
std-proposals_at_[hidden]> wrote:

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