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
On Mon, Nov 20, 2017 at 1:32 PM, Peter Dimov via Boost < boost@lists.boost.org> wrote:
Zach Laine wrote:
On Mon, Nov 20, 2017 at 12:23 PM, Jonathan Coe via Boost < boost@lists.boost.org> 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