> On Aug 24, 2025, at 4:12 AM, organicoman via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>
>>
>> auto val = v[1];
>> creates a copy and does not store a reference even though a reference was returned. You have to write
>> auto &val = v[1];
>
> That's what I referred to as unintentional error.

If you are trying to address UaF you are _definitionally_ trying to mitigate unintentional errors. A proposal that does not prevent or mitigate unintended errors is not addressing the problem. Developers are not intentionally creating bugs. As I have said: your proposal is only solving the trivial cases, that are not generally involved in real world errors precisely because they are so easy to reason about

>> One character missing and the meaning changes, now compare it to your example snippet.
>
> And it is certainly a good idea that operator[] returns a reference because you can also store really large objects inside containers. You might even want to be able to write
> v[1] = 2;

auto &value = someContainer[..];
someContainer.resize(..);
value->thing(); // Use after freee

>> Same function with two actions, that breaks the single responsibility principle.
>
>
> which is only possible with a reference.
> A reference also means you can put non-copyable objects inside the container,

A noncopyable member already has to be passed by reference, this does nothing to stop deletion of the referenced object.

>> That's certainly a bad decision, and I advice against that.
>
>
> like unique_ptr. You see, a reference is almost mandatory here for C++ to succeed

References are literally just syntactic sugar around pointers. They are not special:

T& ref = *new T;

Your model does not make this go away

> If the designer of the type explicity express that his type is not copiable, why fight with his design, and use references?

Copyability is not relevant here - I do not understand how this comment is relevant?

> All what you've said so far can be answered with good argument, but let's not deviate from the main idea.

Then do so.

Multiple people have provided multiple reasons why your proposal/main idea:

* Does not mitigate or prevent UaFs
* Breaks ABI (i.e. is not generally portable, and does not protect existing code)
* Hurts performance by adding additional indirection

You need to explain how your proposal prevents non-trivial UaF that are not already trivially prevented (which literally *every* single one of your examples demonstrates - you cannot involved lexically bound lifetime), how it provides a better solution than simply using smart pointers, if not using smart pointers how you manage lifetime of the storage objects for these references, how it works with references and pointers to subobjects, how it works with pointer parameters without changing the source and compiled ABI.

—Oliver