>I can currently overload + < > * to do this, but not &&. That's broken.
Hm.... I don't recall C++ ever thinking to overload the control-flow
operators ("&&", "||", "," (that is, comma), and "?:"). Why not?
Even if their "a && b" should produce a more mundane 1 or 0, one
still might wish control.
> > if ($whatever) { A }
> > else { B }
> >
> > Why should that any of those be different than
> >
> > $whatever ? A : B;
>Because one is a control and one is an operator (i.e. yields a value).
>What if I want that value to be another ExprTree?
So you're saying that if it produces a value, you should be able
to intercept that. I might buy that, but I'd like to see your
specific examples of the three places you wished for it so that
I could understand what wonders this could provide.
I'm not sure that being able to make everything possible be something
it does not appear to be should *necessarily* be construed a feature.
If you're doing control-flow overloading now, then this opens a new
realm of possibilities and concerns. One should wonder whether if()
should overload to the same as unless().
Or more concretely related to what you're saying, whether we allow
people to toss De Morgan out the window. I do not see how it is a
feature to create a new universe in which
!a && !b
and
a || b
can no longer equated. It strikes me as a bit reminiscent of (one
reason) why Larry didn't make a+b work on strings, since then while
with numbers, a+b and b+a would be the same, with strings they would
not be, and we have these rather deeply held convictions about such
matters.
Yes, I know that the synthetic optimizations with overloading (eg,
if you only have binary +, you can infer += and ++, or you can have
those act completely separately) render this "conviction" slightly
suspect, since now you can do anything you want. So it's not wholly
without precedent.
--tom
