It's still useful to have the range, take std:string(...) for example. It
takes char const * str as an option for constructing with. With a
definitely invalid range it could catch that and initialise to a state that
could indicate the error in release mod while in debug mode it just carry
on and let the segfault happen.

On Thu, 31 Jul 2025 at 16:18, Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Thu, Jul 31, 2025 at 11:09 AM zxuiji via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > It's useful to know a standard range to apply. For example libraries
> like boost could detect if pointers passed to them are in said range and
> catch the problem before a segfault can happen. They can in turn exit the
> thread but not the whole app/game/etc.
>
> And if the pointer is offset so far that it leaves this "bad range",
> then it won't catch anything.
>
> I don't really see the advantage of enforcing highly-platform specific
> elements of memory architecture just for this possibility. The
> cost/benefit just doesn't add up.
>
> And that of course is ignoring the OP's specific desire to use such
> "bad pointers" in an object's destructor, thus requiring the standard
> to actually standardize the behavior of accessing an object's data
> past the lifetime of that object.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>