As some of you have noticed, if you have an expression a.b, we currently
do the following:
1. Find the type of `a`, let's call it T_a
2. Auto-deref T_a to D_a
3. Search for a field b in the type D_a
4. Assuming none is found, search for an impl defining a method b on the
type T_a
As you can see, we search for fields using the deref'd type D_a but
search for *methods* using the original type, T_a. This is plainly
inconsistent. It also leads to annoying things like `(*a).foo()`.
However, the reason we do that is also sensible: we want to be able to
define an impl on a type `@T`, for example.
I was thinking, though, that we could simply change the step where we
scan for matching impls to take both the original and dereferenced type
as input. For each impl, we can then examine the type the impl is
defined for and check either T_a or D_a as appropriate. To decide which
T_a or D_a to use, we examine the type T_f that the impl is `for`. If
`T_f` is dereferencable, we use T_a, otherwise we use D_a.
Examples:
class C { ... }
type R = { ... }
enum kilometer = uint;
impl of X for @uint { } // use T_a
impl of X for option<uint> { } // use D_a
impl of X for uint { } // use D_a
impl of X for C { } // use D_a
impl of X for kilometer { } // use T_a
impl of X for R { } // use D_a
How's this sound?
Niko
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
