From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2008-06-01 07:42:19
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.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk