My vote would definitely be for the expected semantics because if the assignment is present in the program, then the programmer probably knows what they're doing. More importantly, it would avoid the maintenance burden of implementing operator= in classes that have multi_array instances as members.
I agree, and specially because operator= in particular can not be redefined in C++ outside the class. I would honor semantics avobe all but not without some conceptual redesing first, (I wouldn't know WHAT to redesign though :)) , that comes with the unavoidable cost of surprise reallocation and a modification of current behavior of the library. It also poses some questions, should base indices be copied too? what if base indices are different? what if storage order is different? is the storage-order copied? Or suppose the opposite, that we want to forbid reallocation (and for simplicity even reshape) then it will turn out that multi_arrays of different shapes are effectivelly different "dynamic" types(e.g. an array of 10x10 and an array of 20x20 are different beasts although both are the same C++ type). I really don't know how "effective dynamic types" can be formalized in this context except that we could throw and exception like bad_cast or domain_error or size_mismatch or something when using arrays of different shapes. I hope someone goes around this problem in an elegant manner either with or without modifying the library; but yes then, the design goals of MultiArray should be stated more clearly in the first place. I admit that, in the few cases I had to do something about that, I just checked if I have to resize the destination array before assignment, but I was never happy with it. My next idea was to encapsulate the assigment in a function call that creates an object of class assign_helper that has a reference to the multi_array with an operator= that does this check and eventual resizes for me, so I can use it like this: smart_assign(A)=B; // takes care of eventual resize. Used instead of A=B (which may fail), (both A and B are of type multi_array<double, 2> for example.) that was my way arround not being able to redefine operator=; but I am not sure if it is a good idea yet and whether it is a real improvement over just something like 'smart_assign(A, B);'; Regards, Alfredo