On Sunday 01 June 2008 06:34, Felipe Magno de Almeida wrote:
That's a matter of taste, for sure. But would you mind telling us why you don't want to have these? Your opinion sounds to be quite strong, so you must have good reasons!
It's the obvious reason. I don't think taking a function with a 2 letter name, which is already overloaded, and adding a new set of overloads to it which have semantics completely unrelated to the existing overloads is a desirable or aesthetically pleasing interface. No one would even consider doing such a thing if the function wasn't an operator. I guess I just don't find operator syntax as compelling a feature as others.
I tend to agree with Frank's view of overloading && and || for futures. I'm surely not a never-overload-operators-guy. I, for instance, love spirit. But in spirit && and || has a specific meaning inside EBNF domain. In futures, we're just inventing that meaning. Couldn't lambda's help us more than overloading here?
Oh, I came up with another reason. A future can be empty (default constructed, or a moved unique_future). Such classes often support converson to bool (or conversion to "unspecified boolean type" when they want to be safer) to test if they have been initialized. So seeing a future in a logical operator, one might mistakenly assume the operator is is a test to see if either or both futures have been initialized. Although, to nit-pick myself, I don't think the statement I made about the logical operators already being overloaded was technically correct. I suppose its really the conversion-to-bool operator that is overloaded and there is just the bool prototype for the logical operators.