This strikes me as a good point. I think the incongruity this would create between functions and methods -- along with the additional syntactic burden -- could lead to the use of functions feeling second class in some sense. Also, how would static methods be treated?
Cheers, Tim On Wed, Nov 20, 2013 at 8:47 PM, Tommi <rusty.ga...@icloud.com> wrote: > On 2013-11-20, at 18:27, Patrick Walton <pcwal...@mozilla.com> wrote: > > On 11/19/13 9:42 PM, Tommi wrote: > > Our problem is that, given let arg: ~A;, seeing only foo(arg) in code > doesn't tell us whether arg is moved or borrowed. The proposed solution > is that auto-borrowing in that context would be deprecated and thus > would require an explicit borrowing: foo(&*arg). Now, given that it > seems that the upcoming UFCS would simply re-write arg.foo() to > foo(arg), it would mean that seeing only arg.foo() in code doesn't tell > us whether arg is moved or borrowed. Thus, the proposed solution would > fix only half of the problem. > > > Again, I don't see this as an argument against the proposal. The dot > operator is always magical. Magic on one place doesn't justify magic > everywhere. > > Patrick > > > The goal of the proposal is to disambiguate code by forcing programmers to > write foo(&*arg) instead of foo(arg). But I claim that the proposal will > at least partly fail to achieve that goal because programmers will simply > resort to writing arg.foo() rather than foo(&*arg), and we finish where > we started. > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
