On Sat, Feb 22, 2025 at 6:07 PM JOHN MORRISON via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> This is a long post so I have split it into sections so you don't get lost reading it.
>
>
> ---------------------------------------------------------------------------------------------------------------------------------------------
> Who has conflicting design goals? The proposed ptr_to_unique or our criteria for judging if something is acceptable?
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> C++ is an enabling language (I would call it an engineer's language) that lets you construct anything including the means to shoot yourself in the foot or blow your head off. It generally does not a reject a useful feature just because a way can be found of using it wrongly. Although we may use the type system to constrain its use, it has always been the policy that there is no obligation that a feature must come with all the means to prevent its incorrect use. It has always been considered too big an ask that is likely to burden or compromise well formed code or even be impossible to achieve.
>
> However the language is now at a crossroads where there is an existential imperative to reduce its exposure to undefined behaviour caused by coding errors. This impacts on the above policy and has started to produce conflicting criteria in determining if a feature is good to use. Some cases of undetected 'ill formed code' have caused a lot of trouble so now there is a sense that a new feature perhaps should do more to prevent its incorrect use. This is a sense rather than a criteria or policy but it is at play and produces a new perspective.
>
> This crossroads puts the proposed ptr_to_unique in the cross hairs of both perspectives and they are conflicting. It isn't ptr_to_unique that has conflicting design goals, it is our criteria for judging its acceptance.
>
> According to the traditional approach, ptr_to_unique is acceptable because it has a large domain of correct use and incorrect use would be 'ill formed code'. Burdening it with thread checking just in case it is used incorrectly would be considered an abomination where you are paying for something that good code will never use.
>
> However we now feel a need to reduce the opportunities for ill formed code to be written undetected and certainly worry about introducing new ones. The proposed ptr_to_unique is new, it is a smart pointer and ill formed code can be written with it. So naturally that triggers concerns from this new perspective. To address those concerns I have provided thread checking to catch ill formed code at run time but this sorely offends the traditional perspective.

I don't really know what any of this preamble is in response to. You
seem to refuse to reply directly to specific e-mails, which not only
makes it difficult to follow the conversation textually, but it
confuses mail programs (Consider how this thread is presented here:
https://lists.isocpp.org/std-proposals/2025/02/index.php It looks
like you are replying to yourself a lot). It all ultimately feels like
it's out of left field.

But there is also a history of C++ development that is being ignored.
For example:

> It generally does not a reject a useful feature just because a way can be found of using it wrongly.

So... why is `shared_ptr` sharable with threads by default? It adds
overhead to the type, and there are certainly many scenarios where
sharing across threads isn't necessary. So why burden the main
shared_ptr type with this overhead instead of adding two types?

Because safety is *always* something that should be considered.

Safety is the reason `unique_ptr` and move semantics exist in the
first place. It's the reason members can be declared `private`. It's
the reason constructors and destructors exist, along with the various
elements of the object model.

C++ has *always* been in tension between safety and utility.
Presenting this notion as if this is some new-fangled paradigm is just
incorrect.

Making threading a first-class citizen of the language means that the
threading interactions of everything added to the language ought to be
considered. And adding a feature that is actively hostile to threaded
use is... a tall ask.

>From a behavioral standpoint, your `ptr_to_unique` is not a pointer.
Its mechanics are more akin to a reference to a `unique_ptr`, similar
to `reference_wrapper`. And reference types like `reference_wrapper`
are inherently dangerous tools. That's not to say that we can't use
reference types, where appropriate. Types like `function_ref` have
been added because their utility outweighs their safety.

The main issue I have with this type is that its reference mechanics
are unsafe in a different way from other reference types.

`function_ref` cannot work if the object it references has been
destroyed. But this form of breakage is threading-agnostic. It doesn't
matter if that destruction happened on a different thread; the object
is broken either way. That is, reference types are just as dangerous
single-threaded as they are multi-threaded (obviously threading allows
for more *potential* for problems).

Your `ptr_to_unique` reference *does* work if the object it references
has been destroyed... sometimes. And that's the problem. Your type
explicitly singles out threading in a way that general reference types
*don't*. Yours works if the lifetime of the referenced object ends, so
long as that happened on this same thread.

That is a very different paradigm, and I cannot think of a type in C++
that behaves that way. Iterators are invalid if the range they contain
has been destroyed; it doesn't matter if that happened on this thread
or a different one. `reference_wrapper` doesn't work if the thing it
references is destroyed regardless of threading. `weak_ptr` works
regardless of where the destruction happens. Etc. I don't know of a
case where a reference type works with a destroyed object, but only if
it was destroyed in this thread.

So what we have in this `ptr_to_unique` is a type with extremely niche
functionality (ie: most people won't be familiar with it) coupled with
being brittle in a way that is unique in the C++ standard library.

So if I'm extracting some code into another thread (possibly by just
calling it from a coroutine), and I do a code-review to look for
problems, it is very likely that I won't look up the documentation for
this specific object. I see that it's being held by value, which is
usually a sign that it can work across threads. I see that it is
accessing a pointer stored in that object, but I also see from the API
that it checks if the pointer is valid. So from a first-pass visual
inspection, this ought to work.

That fragility coupled with its niche utility makes me feel that it's
not something that needs to be a standard library type.