On Wed, May 29, 2019 at 12:23 PM Zach Laine via Boost
On Wed, May 29, 2019 at 11:09 AM Andrzej Krzemienski via Boost < boost@lists.boost.org> 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