I guess I just don't see the value in requiring imports of names when there can
be no ambiguity and they're defined in one place (the impl of the type, defined
in the same place as the type itself). One person's "magic" is another person's
"smart compiler".
I'm not convinced that this is solving a real problem. The "search all traits
in scope" behavior strikes me as far more magical than this. Doing type-based
lookup without imports, if the names all had to be defined in one place, seems
like a bog-standard language feature to me. It's probably easier to list
languages that *don't* have this feature in some form than to list languages
that do, honestly...
Patrick
"Gábor Lehel" <[email protected]> wrote:
>On Sun, Oct 20, 2013 at 8:16 PM, Patrick Walton <[email protected]>
>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.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
