I am more concerned about point of deletion than creation as in your
example.

struct inner
{
    void do_something(){}
};

struct outer
{
    inner& i;
};

outer f1()
{
    inner i
    return outer{i};
}

f1().i. do_something();// crash hopefully

The question is ensuring that the default destructor of outer setting its
INTERNAL pointer of i to nullptr instead of it being a noop and the
destructor being elided for having no code.


On Fri, Jul 25, 2025 at 7:33 AM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:

> On Fri, Jul 25, 2025 at 12:24 PM Jarrad Waterloo wrote:
> >
> > Frederick,
> >
> > I know that references can't be EXPLICITLY set to nullptr.
> > Could something like this be used to say that INTERNALLY
> > references are set to nullptr or 0xdeadbeef, even in production,
> > to ensure that we get a segfault if the memory hasn't been overwritten?
>
>
> I think you're saying that an alteration would be made to the
> compiler, so that if it ever encounters a reference, and if the
> reference internally refers to an object located at 0xdeadbeef, then
> the compiler (not the debugger) will put code inside the binary that
> kills the program and explains what went wrong?
>
> Actually I'm not totally sure what you're saying . . . maybe you're
> talking about the point at which the reference is created, so for
> example when the compiler sees the following when NDEBUG is not
> defined:
>
> MyClass &ref = *(MyClass*)badptr;
>
> It emits code that checks if the referred object lives at 0xdeadbeef,
> and if so, it kills the program and gives an explanation?
>
> Compilers, when building debug binaries, could emit extra code to
> always be checking for 0xdeadbeef.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>