Re: [boost] Adding polymorphic_value to boost

Subject: Re: [boost] Adding polymorphic_value to boost
From: Jonathan Coe (jonathanbcoe_at_[hidden])
Date: 2017-11-22 09:05:26

> On 22 Nov 2017, at 07:40, Richard Hodges via Boost <boost_at_[hidden]> wrote:
> 
> 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
>> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Thanks for taking the time to write this. If any of your thought experiments graduated to full code snippets, I’d love to see them. I’m sure you won’t be the last person who would like to see justification for const-propagation

Regards

Jon