Re: [boost] Adding polymorphic_value to boost

Subject: Re: [boost] Adding polymorphic_value to boost
From: Jonathan Coe (jonathanbcoe_at_[hidden])
Date: 2017-11-20 20:08:51

On 20 November 2017 at 20:01, Robert Ramey via Boost <boost_at_[hidden]>
wrote:

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