Re: [boost] Adding polymorphic_value to boost

On 22 Nov 2017, at 07:40, Richard Hodges via Boost 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 wrote:

...

...

...

On 21 Nov 2017, at 17:30, Seth via Boost 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