AMDG On 11/20/2017 01:11 PM, Richard Hodges via Boost wrote:
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.
None of these make copies. polymorphic_value is not called XXX_ptr precisely because its semantics are different from a pointer.
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).
This situation doesn't make sense for polymorphic_value.
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?
In Christ, Steven Watanabe