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
This would be at odds with the behaviour shared_ptr, unique_ptr, and
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
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
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
This feels to me like idealists overriding pragmatists.
Or have I missed something obvious?
On 20 November 2017 at 20:41, Zach Laine via Boost <boost_at_[hidden]>
> 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.
> Unsubscribe & other changes: http://lists.boost.org/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk