On 6/14/12 10:23 AM, Graydon Hoare wrote:
But this general move feels like obscuring a pretty important bug,
that I'm inclined to point out: we need to expand operator overloading
to have op= forms, in general, such that a user could _define_ a
version of += that does what the compiler currently does, when that's
reasonable (overload arg-type symmetry aside). Operator overloading is
simply incomplete here; likewise, fn [](...) needs to have a 3-arg
lval form, not try to "return a mutable ref" or something.
This makes sense. I don't have a problem with adding a += operator, but
there are... interactions. Nothing too complex but nothing that we have
designed for. In general our operator overloading support is minimal
and somewhat ad-hoc. We should sketch out a complete plan that accounts
for these various complexities.
One thing: right now, x += [5] is extra optimized in that it does not
create the RHS vector. I ddn't see how any form of operator overloading
will achieve *that*. We may want to create additional operators (e.g.,
++) to distinguish addition of elements / vectors. I know Marijn is in
favor of this (or at least he was at some point).
What are the shortcomings of overloaded operators? Here are some things
I can think of.
- No way to do x += 5
- x[5] = 3 only works for built-in types
- x[5] += 3 only works for built-in types
- &x[5] only works for built-in types
The questions then are:
- Which of these patterns should we support at all?
- Which can be implemented directly and which are desugared?
- For desugaring, what fallbacks are in place?
- Finally, how can we possibly implement this in our compiler in a nice way?
I think the current implementation of overloading is fragile, in that it
affects every downstream client which must consider "two ways" of
interpreting a random set of expressions (expr_unary, expr_binary,
expr_index, maybe others). This accounts for several bugs (eholk just
found one the other day). I was thinking of refactoring things so that
all operators ALWAYS have an entry in the "overload" table, and one of
those entries is the "intrinsic" definition. So then we can treat
things are overloaded operators all the time in the later analysis
passes and only trans has to special case things (and maybe not even
that, if we use actual rusti intrinsics?) This will get even more
complex when x[5] += 5 might be a call to "[]+=" or it might desugar to
"x[5] = x[5] + 5". (This all points to the ever-present desire for a
rewriting IR, but I don't have any brilliant suggestions on that front)
Niko
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
