Re: [boost] Adding polymorphic_value to boost

Subject: Re: [boost] Adding polymorphic_value to boost
From: Richard Hodges (hodges.r_at_[hidden])
Date: 2017-11-20 20:11:28

I watched Sean Parent's talk covering what has now become polymorphic_value.

One thing that I am concerned about is Sean's insistence on propagating
const implicitly.

This would be at odds with the behaviour shared_ptr, unique_ptr, and
reference_wrapper.

Sometimes I want a const pointer to a mutable thing, and sometimes I want a
mutable pointer to a const thing (and sometimes I want to be able to
observe a thing without affecting its lifetime).

So my 2-pence would be that propagate_const should not be implicit in this
class.

My rationale is that an obvious use case for me would be manufacturing
specialisations on pointer_type allowing a consistent interface leading to
an inner implementation while simply changing ownership behaviour.

In that sense I am strongly of the view that the return type of
polymorphic_value<Foo>::operator*() const should be Foo& and not const Foo&.

If I want a polymorphic cloning pointer to const Foo I can declare it with
polymorphic_value<const Foo>.

I have never had reason to quibble with Sean's thinking before now, but on
this he is dead wrong.

If I want const propagation, it's simple enough to wrap any pointer in
propagate_const<>

This feels to me like idealists overriding pragmatists.

Or have I missed something obvious?

R

On 20 November 2017 at 20:41, Zach Laine via Boost <boost_at_[hidden]>
wrote:

> On Mon, Nov 20, 2017 at 1:32 PM, Peter Dimov via Boost <
> boost_at_[hidden]> wrote:
>
> > Zach Laine wrote:
> >
> >> On Mon, Nov 20, 2017 at 12:23 PM, Jonathan Coe via Boost <
> >> boost_at_[hidden]> wrote:
> >>
> >> > 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.
> >>
> >> To answer the proximate question, LEWG wanted nothing to do with
> >> clone_ptr, whether or not it is designed to support or interoperate with
> >> polymorphic_value.  Jonathan, please correct me if I'm wrong.
> >>
> >
> > OK, but this makes the submission a bit different than ordinary.
> >
>
> True enough.  This exact scenario is unique AFAIK.
>
>
> > Usually, in the course of the Boost review process, reviewers suggest
> > changes and improvements, and can base their acceptance vote on some of
> > these changes being applied.
> >
> > If I understand correctly, polymorphic_value as proposed is not open to
> > any changes, because it has already been blessed by the LWG. Done and
> > dusted.
> >
>
> That's not my understanding, nor what I expect.  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.  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.
>
> Zach
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>