Re: [boost] [Boost-users] [multi_array] Everyone, please make your value-types Assignable!

From: Daryle Walker (darylew_at_[hidden])
Date: 2008-07-20 05:18:13

On Jul 20, 2008, at 1:46 AM, Sean Parent wrote:

> I think there are two separate notions being discussed here -
>
> First is the notion of a partial function - assignment and copy are
> both partial functions and have a precondition that the rvalue be in a
> valid state.

This is the case that Dave brought up.  I think it shouldn't be the  
main concern because: (1) non-PODs are generally always in a valid  
state when created and (2) it's already illegal to use a not-(fully-) 
initialized (POD) object as an r-value.

My main concern was what happens when a type's designer divides that  
type's set of valid states into multiple "runtime types" (as you say  
below), but the user wants to be more flexible with cross- 
compatibility than the designer.

> The second is the notion of a runtime type where once the type is
> determined it is fixed and assignment becomes defined only on items of
> the same type. I tend to shy away from
> implementing such types and usually prefer to document that
> assignment won't throw
> (perhaps unless some subtype throws) if the two objects are of the
> same runtime type (or have the same topology - or whatever a correct
> term would be for the circumstance).

The problem comes from regular (copy-)assignment being considered a  
special function. Library code makes assumptions that don't work if  
assignments aren't free-for-all.  User code that wraps runtime types  
have to either add an invariant that all uses of that type are of the  
same assignment-compatibility class or do appropriate  
reconfigurations (or give up with an assertion or exception) when two  
objects of different a.c. classes clash.

> There are cases where I think the notion of a runtime type is valid
> even when it makes assignment more partial than it would be otherwise
> - being partial doesn't effect the concept at all - but such a design
> choice should be weighed carefully.

Yes.  I think an important thing to do for such types is to make sure  
that swap stays never-fail, like destructors and deallocators, by  
making sure it works even when the two objects are of different a.c.  
classes.  That way:

     my_class &  fake_assign( my_class &dest, my_class const &sour )
     {
         my_class  copy( sour );
         copy.swap( dest );  // even if either "copy=dest" or  
"dest=copy" would fail
         return dest;
      }

anyone who needs to assign across a.c. classes can work-around it and  
still have the option of the strong guarantee.

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com