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-22 07:40:21

Jonathan Coe wrote:

> I would agree that polymorphic_value and cloned_ptr solve different
problems. My proposed addition to boost is polymorphic_value, I could
possibly be convinced to propose cloned_ptr too.

After making my bold claims of the wrongness of propagating const by
default yesterday (in the light of writing reactive I/O services), I have
taken some time to go back over old code and re-reason in terms of
polymorphic_value.

My concern was around scenarios where the outer handle on the main thread
wants to do something "constful" to the implementation, but this would
require non-const access to the impl by a resulting closure or handler
running in the IO thread.

Embarrassingly it turns out that under these circumstances the only time I
ever need mutable access are:

1. to mutate a mutex - which can of course be solved by making the mutex
mutable.

2. to modify a "use count" - in which case the solution is angling towards
a shared_ptr or intrusive_ptr implementation handle anyway.

So on balance, although on grounds of interface consistency it pains me to
say it, I am forced to agree that there is no harm in my use case in
propagating constness, and I certainly accept that propagating const makes
the writing of handle-body value-types less error prone, and in this
scenario is definitely a _good thing_.

In short, I am persuaded.

Thank you for your patience.

R

On 21 November 2017 at 20:08, Jonathan Coe via Boost <boost_at_[hidden]>
wrote:

>
>
> > On 21 Nov 2017, at 17:30, Seth via Boost <boost_at_[hidden]> wrote:
> >
> >> On 21-11-17 09:45, Jonathan Coe via Boost wrote:
> >> Do you have sample code you might be able to share to illustrate this
> >> point: "Sometimes (in a comms-based system, often) even though the
> handle
> >> object's
> >> interface is const, and accessor will do some internal work which may
> >> need to mutate the implementation (even on another thread)." I'm afraid
> >> this example is sufficiently removed from my day-to-day experience that
> I
> >> struggle to see what you mean without code.
> >
> > I'm not sure, but I'm seeing `handle` as something completely different,
> > unrelated to `polymorphic_value`.
> >
> > The implementation of a handle's body could benefit a lot from
> > `polymorphic_value`, but
> >
> >  - in my mind a `polymorphic_value` has - by definition - value
> > semantics, and a such _requires_ const-propagation always (because
> > that's consistent witht he core language value semantics).
> >
> >  - likewise, the const-ness of a handle never propagates to it's body
> >
> > Different patterns, different semantics, different type, I think
> >
> > Cheers,
> >
> > Seth
> >
> >
> > _______________________________________________
> > Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>
> I would agree that polymorphic_value and cloned_ptr solve different
> problems. My proposed addition to boost is polymorphic_value, I could
> possibly be convinced to propose cloned_ptr too.
>
> Regards
>
> Jon
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>