"Andrei Alexandrescu \(See Website for Email\)" <andrewalex@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u658z4xrh.fsf@boost-consulting.com...
Well, it might.
But then, the user knows he's using the initialization library, and operator, has a different meaning in that context, just like operator<< means something else in the context of a Spirit gramar.
I see. So I'd like to make a quick poll for Boosters: Overloading the comma operator in a way that could change order of evaluation of its arguments is:
a) an obsolete coding standard b) a valid coding standard c) a valid coding standard, but for reasons x, y, and z, the initialization library doesn't violate it/violates it but gets away with it/etc.
IMO it's only a valid coding standard if you also have a coding standard that says "operators must always act the same on user-defined types as they do on the builtins" -- which I would never accept ;-) Probably the right standard is: "If you're trying to define operators that act like the builtin ones, beware the overloading of operator,, operator&& and operator||, because you can't get identical semantics". But then, why would anyone want to overload operator, other than to change the semantics?? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com