On 20 November 2017 at 20:01, Robert Ramey via Boost
On 11/20/17 11:41 AM, Zach Laine via Boost wrote:
On Mon, Nov 20, 2017 at 1:32 PM, Peter Dimov via Boost <
... I'm one of the people who
keeps insisting in LEWG that things go through Boost (or other avenues of widespread use) before being standardized.
+1
My expectation is that the
review will be very instructive, even if the library is rejected. Rejection is actually a very important data point! I would expect LEWG to delay standardization or to do a substantial re-think of whether this should be standardized at all if it is rejected.
So Jonathan does not actually solicit feedback. It is what it is, take it
or leave it.
I think that overstates it a bit, having talked to Jonathan about this. Again, Jonathan can correct me if I'm wrong.
FWIW - I think that boost should approach this as it always has. That is, either reject, accept or accept with some modest conditions.
And I think the committee should do what IT usually does: accept, reject, or redesign leveraging on experience as provided by users and vendors.
Boost and the Committee are related, but they are not the same. If they were, one would be superfluous.
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost
That's exactly what I'm hoping for. I don't want polymorphic_value to be given any form of special consideration. When I said "I’m proposing adding polymorphic_value to boost, not cloned_ptr. My submission to boost is intended to mirror my submission to the C++ standards committee." I did not mean that I do not want feedback, but that cloned_ptr is not part of my proposed boost library submission. LWG may yet reject polymorphic_value and I would hope that their decision will have little bearing on the boost review process. I include Sean's explanation of why cloned_ptr is 'broken' and why polymorphic_value is not: "The primary semantics of a “pointer” or “handle” type is that it is an object that refers to another object. Copying a pointer does not copy the underlying object, two pointers are equal if they refer to the same object. The relationship between copying and equality also extends to the semantics of const. A const pointer is distinct from a pointer to a const object. If we have a const object and make a copy of it, any operation on the const object should not modify the copy. Copying a polymorphic_value, copies the remote part. If we were to implement equality of a polymorphic value it would be by virtualizing a call to operator==() on the remote part. A const polymorphic_value also implies the remote part is const. These are value, not pointer, semantics. The requirement of using operator*() and operator-> for an object with value semantics is an unfortunate (but not unprecedented) hack. Unfortunately, we cannot overload operator.() so overloading the dereference operators are the best we can do. The same is true of std::optional, which also has value semantics. polymorphic_value, IMO, creates a nice balance between full type erasure (using something like Facebook’s (Eric Niebler’s) Folly/Poly library) and traditional inheritance with specified interfaces. It is also useful in non-polymphric settings (which is why I somewhat prefer the name “indirect_value”) where one wants to make the tradeoff to gain an efficient move operation and the expense of a heap allocation. polymorphic_value should not be called a “pointer” because it does not have pointer semantics anymore than std::optional or std::vector are pointers." I look forward to improving this already useful library utility with the help of the boost community.