Re: [boost] Adding polymorphic_value to boost

Subject: Re: [boost] Adding polymorphic_value to boost
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-11-20 21:41:22

AMDG

On 11/20/2017 02:12 PM, Richard Hodges via Boost wrote:
>>  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.
> 

  This is stated in an overly general way to artificially
make it cover cloning_ptr.  Copying objects is in no way
an extension of deleting objects when they are no longer
needed.

> 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.
> 

  You shouldn't think of it as a pointer.  polymorphic_value
is not a pointer that copies automatically.  It's a value
that allows runtime polymorphism.

> 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.
> 

How is it not 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).
> 

  I don't understand what you mean.  The most important
feature of a "value" is that copies are disjoint, which
is precisely what copying the stored object guarantees.

In Christ,
Steven Watanabe