Re: [boost] Re: multidimensional arrays (was Boost Mathematicians)

From: Topher Cooper (topher_at_[hidden])
Date: 2004-07-12 13:15:29

Putting my two cents in on the issue of redefining the meaning of 
"operator,".

Summary: Bad idea.

The redefinition of "operator<<" for the I/O libraries is an entirely 
different situation.  Before that was done, the specific meaning of the 
operator depended, however simply, on polymorphic resolution of the 
left operand.  Use of the operator for streams -- though frequently 
confusing at first until it became, effectively, an accepted part of 
the language -- simply extended this fact rather radically.  The 
complete meaning of the operator was now different rather than simply 
some of the details, but this is within the continuum of meanings.  
Now, as before, to understand what the operator meant -- if anything -- 
you examined the class of the first operand.

The situation is very different for "operator," however.  Sans 
redefinition it has a well defined meaning for every object that 
(despite the formal situation) is varied (and only in the matter of its 
return type) only through the *second* operand.  Seeing an expression 
of the form "x, y" there is no interpretive moment equivalent to 
stopping to think just what it means to "shift an output stream left."  
As it stands, "x, y" has a clear meaning -- evaluate x then evaluate y 
and use the latter as the value of the complete expression -- UNLESS 
someone somewhere has overloaded the operator.

Overloading "operator<<" as in the I/O libraries *extends* its meaning. 
  Overloading "operator," redefines its meaning.

Are people aware of the ordering implicit in the *normal* usage of the 
"," operator?  Of course, look at how it is taught.  It is described as 
a sort of "weaker" version of ";" that can be used within expressions 
without terminating the statement the expression appears in.  Do they 
understand the sequential nature of ";".  Of course.  Do they 
understand the sequential nature of ",", at least in many cases, if 
they remember that "," within expressions exists at all, they remember 
that it acts sort of like ";" and therefore they probably understand 
its sequential character.

Overloading "operator," is something like overloading "operator==" to 
mean something entirely unrelated to equality or equivalence -- only 
worse.

Looking at this from another viewpoint:  If there is no standard that 
allows generic programmers to assume that "operator," can be assumed to 
act according to its "default semantics", then they should stop using 
"operator," except to make use of some specifically overloaded 
semantics.  Otherwise, the generic code is indeterminate (OK, you could 
use it by being very careful that no value dependent on a generic type 
was involved, but you would still be simply hoping that no one had 
added an overload involving one of your non-parameterized types).

I strongly recommend that "operator," not be overloaded.  If it is 
decided that this is absolutely essential, then I recommend that a 
strong and precise statement first be drafted stating unambiguously 
when such overloading should be "acceptable".

Topher