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