Date: Wed, 28 Oct 2026 13:34:57 +0000
On Wed, 28 Oct 2026 at 13:29, 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.
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*).
But the basic_string(nullptr_t) constructor doesn't help that case, because
NULL is just 0 on most implementations, not nullptr.
> 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
>
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*).
But the basic_string(nullptr_t) constructor doesn't help that case, because
NULL is just 0 on most implementations, not nullptr.
> 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
>
Received on 2026-10-28 13:35:18
