On Sun, Oct 20, 2013 at 8:16 PM, Patrick Walton <pwal...@mozilla.com> wrote:
> 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. > Well, it would do type-based resolution based on the methods which you import :). You would still be the one doing the importing, instead of it happening by magic. You could also /not/ import one or more of them, if you wanted to, which you can currently only do on a per-trait granularity. And the rest of the design would still be much cleaner. (Again, leaving to modules what can be done with modules.) But FWIW, I think this is mostly orthogonal. If you use dot syntax, method lookup happens [somehow]. If it fails, you can do the other things. Maybe method lookup happens with type-based resolution, as it does now. Or maybe it requires that the name itself be unambiguous (which is simpler and dumber), as with functions. That's not really the part I care about. The part I care about is the separation of concerns. > 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. > I still can't speak to the method resolution code :), but I think this would be a positive step. (Requiring the explicit `self` argument would probably make sense, if this were to happen.) -- Your ship was destroyed in a monadic eruption.
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
