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 21:12:54

>  None of these make copies.  polymorphic_value is
> not called XXX_ptr precisely because its semantics
> are different from a pointer.

shared_ptr, unique_ptr and reference_wrapper are all "different" from a
pointer, but they all share 4 common traits:

1. The all manage/observe lifetime of another _single_ object in some
defined but distinct way.

2. They all allow access to that object through operator*

3. They don't propagate const.

4. they don't have any pointery arithmetic behaviour

Looking at the design history of polymorphic_value it seems that it
originally came from a desire to complete the circle by providing another
XXX_ptr which supported copying.

This aim is _eminently useful_ as is evidenced by the numerous
implementations of things like it on github (and in my own code).

I also have an interest is such an object as standard because I always seem
to end up needing one.

I do not have a use case for a const-propagating one. Never have. I can
specify const in the angle-brackets. I've done that probably once.

> This situation doesn't make sense for polymorphic_value.

To you perhaps. However I have 3 projects on the go right now which could
use polymorphic_value immediately as a retro-fit for home-made solutions
*if it did not propagate const*.

The concept of propagating const I can deal with trivially. To incorporate
it into this class mixes concerns to the detriment of its usefulness (to
me).

So If it came to a vote and my voice had any weight, I would say:

* with implicit const-propagation - NO

* remove the const propagation - absolute YES

additionally, ideally rename it back to cloned_ptr, (or indirect if you
must). Because what it is absolutely not is a value.

It is logically the same as the other 4 non-pointers listed above, it's
just that it have different owned-object lifetime behaviour.

I completely understand the value-centric argument. I am a strong proponent
of it.

My argument is that this is (or ought to be) a tool for *building* value
types. It is not in of itself a value type, and neither can it ever be. It
does not exhibit any "value" behaviour (equality and the like).

R

On 20 November 2017 at 21:35, Steven Watanabe via Boost <
boost_at_[hidden]> wrote:

> 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
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>