I just pushed a change to incoming that supports autoderef on method
calls. The ultimate system I ended up with is a bit different from what
was initially discussed on the mailing list, so I wanted to specify how
it works and why.
The basic rule is that we will try to find an impl for the type of the
receiver using the existing rules. If no impl is found, then we will
attempt to autoderef the receiver and search again. This repeats until a
match is found or it is not possible to autoderef. In particular, this
means that if there is an impl for @T and an impl for T, and the
receiver has type @T, then we will use the @T impl.
I had originally planned to report an ambiguity but I changed my mind
after seeing the following impl in the to_str module:
impl<A: to_str> of to_str for @A {
fn to_str() -> str { (*self).to_str() }
}
This implements a pattern like Haskell's deriving. It is inherently
ambiguous when combined with autoderef on method receivers. And yet it
serves a purpose that autoderef on method receivers does not. For
example, using that impl, I can write a routine like:
fn connect<A: to_str>(v: [A], sep: str) -> str {
let mut base = "";
for v.each { |e| base += e.to_str() + sep }
ret base;
}
and I can apply `connect()` to types like `[@uint]`, where `to_str` is
defined to `uint`.
Niko
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
