On 7/26/12 12:52 PM, Gareth Smith wrote:
One way to change this code would be to make the impl for &fat rather
than for fat, and change x's expression to &fat(). Luckily this also
seems to allow calling methods on @fat and ~fat types. Is this a
reasonable way to migrate the code? Are their alternatives?
Summary: we plan to make it possible for you to call methods on a
variable of type `fat` even if those methods are defined on `&fat`. But
it doesn't work yet.
Details: There is some debate about this. So, it seems that the best
thing is to define your methods on &fat. However, this means (as you
observed) that if you have a local variable `x` of type `fat` you can't
call methods on it without something awkward like:
(&x).fat(...)
My original thought was that you would define the variable to be of type
`&fat`, as you suggested. This seems to have a nice orthogonality to
`@fat` and `~fat`. However, there is a downside: an `&fat` value is
aliasable and hence less flexible. You can't, for example, send it to
another task.
So Patrick suggested that method call could "auto-deref" but also
"auto-ref" . That is, if you write `x.y()`, where `x` has type `T`, we
will take the address of `x` and call methods defined on `&T`. This is
rather like C++, which defines methods on T but then the receiver has
type T*.
This would replace the current rule that will allow methods defined for
`&T` to be called on `@T` or `~T`. That instead becomes a consequence
of one auto-deref (to reach the receiver type of `T`) and one auto-ref
from there (to `&T`). So the receiver effectively becomes `&*T`. In
fact, this is the same as today, except that it occurs on one step: the
type system allows `@T` to be converted to `&T`.
Niko
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
