Re: [ boost.out_ptr ] [ Review Endorsement ] New Library targeting C++11

From: JeanHeyd Meneide (phdofthehouse_at_[hidden])
Date: 2019-05-29 22:26:37

On Wed, May 29, 2019 at 12:23 PM Zach Laine via Boost <boost_at_[hidden]>
wrote:

> On Wed, May 29, 2019 at 11:09 AM Andrzej Krzemienski via Boost <
> boost_at_[hidden]> wrote:
>
> > It is my understanding that the library has been first submitted for
> > standardization, and accepted by LEWG. The potential Boost review will
> take
> > place after it has been accepted to the C++ Standard Library. Or am I
> > missing something?
> >
> > Regards,
> > &rzej;
> >
>
> Well, there is a pretty long process between now and a final C++20
> standard, including National Body comments and their resolutions.  If we
> review out_ptr soon enough, we can still use that feedback.  The usable
> feedback effectively only applies to fixing problems, not tweaks in the
> design.  After C++20 finally ships, we're stuck -- even if we find big and
> easy-to-fix problems.
>
> Zach
>

The library was actually submitted for Boost first before the making it to
LWG, given that was part of the feedback from the first time it was
reviewed in San Diego. It was discussed at the Boost Dinner to put the type
through the Boost Review process, but to also consider putting it in a
pre-existing library (boost.movelib and boost.smart_ptr). I chose the
pre-existing library route, but given design decision and time constraints
was encouraged to submit it as an independent library instead. Had the
earlier routes (pre-existing libraries) been deemed appropriate, this would
have been in Boost by 1.70, before being forwarded to LWG.

The good news is, LEWG has control over the design of the thing: CTAD
versus no CTAD, factory functions, customization point design, etc.: all of
that is fine and should be staying the same barring a catastrophe. What's
up in the air is the exact wording of the specification, which I believe a
Review will be incredibly helpful with.

Gavin Lambert:

     The implementation (and wording on the reference docs and reference
paper) were scaled back to always initialize `p` with its value
initialization and not to allow for any optimizations. I suspect this might
be a sticking point for some who have APIs that take care of setting the
nullptr for them, and they would likely benefit from a performance using
out_ptr that aliases / reseats the pointer directly (as my implementation
had been doing to gain performance benefits in the benchmarks over the
"simple out_ptr" benchmark case). The good news is, nothing about this
precludes boost (or the Standard) from creating a new factory function or
type in the case where the user holds certain expectations over the
function call they are using. My current thought is that maybe a tag type /
tag object going as the first argument can help indicate that it is
"non-nullptr safe"... but that's more design that lies outside the scope of
this proposal and review.

Sincerely,
JeanHeyd Meneide