But then it seems strange to require that the methods be imported at all, if
you're going to do single-dispatch type-based resolution on them anyway.
What we could do, perhaps, is add a third source of methods that the dot
operator searches: functions in scope. This would allow methods to be attached
anywhere to pre-existing types in an ad-hoc basis. I'm a bit nervous about
complicating our already-complicated method lookup further, but maybe it makes
sense to reduce the number of FooMethods traits people have to write, as well
as to accommodate function chaining patterns.
Patrick
"Gábor Lehel" <illiss...@gmail.com> wrote:
>On Sun, Oct 20, 2013 at 8:01 PM, Patrick Walton <pwal...@mozilla.com>
>wrote:
>
>> What would happen if two types defined a method called, say, "foo",
>and
>> the importing module glob imported them both?
>>
>
>Here's the part where I have to say that I'm not intimately familiar
>with
>how Rust's existing method lookup works. But I don't see why it would
>necessarily have to work any differently from the way it does now. If
>you
>use dot syntax, it would try to do type-based name resolution (i.e. use
>the
>method in scope whose self-type matches), autoborrowing,
>autoreferencing,
>and whatever else it currently does to try to get an unambiguous match.
>If
>that fails, *then* you would have the option of tweaking your imports,
>`use`ing the method under a different name, or switching to function
>syntax
>and adding an explicit module qualifier (along with explicit borrowing
>and
>whatever).
>
>--
>Your ship was destroyed in a monadic eruption.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
