On 28 Oct 2026 16:34, Jonathan Wakely wrote:
>
> On Wed, 28 Oct 2026 at 13:29, Andrey Semashev via Std-Proposals <std-
> proposals_at_[hidden] <mailto: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.
>
> You might be surprised how often people try to do:
> std::string s = NULL;
> thinking this is the correct way to get an empty string (probably used
> to doing it for const char*).

Given that NULL is not an empty C string either, those people are likely
very very new to both C and C++. You can't protect against every
incorrect code a novice writes.

> But the basic_string(nullptr_t) constructor doesn't help that case,
> because NULL is just 0 on most implementations, not nullptr.

Right, so not so helpful constructor after all.