On 7/16/2020 2:14 PM, Arthur O'Dwyer via Std-Proposals wrote:
> 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!

I'm not sure what that code looks like, but it sounds terrible!

>
> 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.

(1) Mistake on my part, I'm not sure what I was thinking. I think I was
thinking of the default constructor for some reason.
(2) You are correct, that is a typo. It should be explicit.

>
> 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.
> :))

Thanks for the references!

-Jefferson