On Thu, Jul 16, 2020 at 6:24 AM Jefferson Carpenter via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
> I've written this ptr class for myself, and it's truly a joy to work
> with. It sits in between std::shared_ptr and std::unique_ptr in terms
> of safety and speed.
>
> I do not know if it would be a good addition to the C++ standard, since
> it's pretty easy to implement, and would take up space.
>

One of the codebases I currently work on has the same kind of thing for
expression trees, except with pseudo-value-semantics: instead of saying "I
have a *pointer *that may or may not be owning," we say "I have a *tree*
which I may or may not be responsible for cleaning up." This was originally
done for convenience when referring to a subtree: user A can refer
non-owningly to a subtree of a larger tree that is actually owned by user
B. Both user A's and user B's "tree" objects have the same type and can be
passed to the same callees.

We have differently spelled accessors for "give me an O(1) 'copy' that is a
nonowning reference to this same (sub)tree" and "give me an O(n) copy that
actually makes a copy of this (sub)tree and then owns it." Figuring out
which to use in any given situation is an art.

I consider it a *nightmare *to work with!

Admittedly we don't call it a "ptr" but a whole "tree" (naming is hard!),
and we have the added wrinkle of being able to confuse subtrees with whole
trees... but I would be fairly adamantly against ever introducing anything
even vaguely along these lines into any codebase I ever worked on. It's
just a huge mass of dangling-pointer bugs waiting to happen.

I expect that the potential for dangling-pointer bugs means that the
Committee won't be thrilled with your proposal either.

Significant technical issue with your spec: You give your type a
constructor overload set containing
    (1) ptr(ptr) — This is invalid. I'm not sure what you meant to type.
    (2) ptr(T*) — You specify that this constructor is non-explicit, and
that it creates a non-owning ptr. That's problematic because every other
smart-pointer type in existence has an *explicit *constructor that creates
an *owning *ptr. You should follow their lead, or else discuss in the paper
why you're striking out on your own.

See also P0468r1
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0468r1.html> and
P1351r0
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1351r0.html>,
especially the latter's section "Retain by default." (It's unfortunately
very terse and doesn't explain much. Your paper should explain even better.
:))

–Arthur