On Sun, Oct 20, 2013 at 5:28 AM, Gábor Lehel <illiss...@gmail.com> wrote:
> On Sat, Oct 19, 2013 at 10:52 PM, Patrick Walton <pwal...@mozilla.com>wrote:
>
>> I think it's unfortunately too late to overhaul the language like this.
>> This will require redesigns of all Rust code in existence.
>>
>> I do like unified function/method call syntax, but I think it can be done
>> in a backwards compatible way.
>>
>
> This is up to you and the rest of the Rust team, of course. But in my very
> humble opinion, it feels shortsighted to impose backwards compatibility
> constraints at this point. All Rust code in existence is still (hopefully!)
> a negligibly small fraction of the code that is yet to be written. I know
> there's a desire to get 1.0 out the door as soon as possible, and I
> understand it (I want to be using Rust instead of C++, too!), but if Rust
> is still in use years or decades from now, decisions made now about the
> design of the language will echo far louder than whether it was released a
> few months earlier or later. I think it would be unfortunate to start
> suffering a C++-like fate sooner than absolutely necessary.
>
The Go team has been able to make incompatible language & library changes
by providing a tool that updates existing programs. Since Go's
pretty-printer fully defines the appearance of source code (indenting, line
wrapping, etc.), the updater can't mess up such things (and there are no
debates about them).
> That was a general argument, and it only matters if something is
> considered a good idea on the merits. In this case, it seems we disagree
> about that:
>
>
> On Sat, Oct 19, 2013 at 11:46 PM, Patrick Walton <pwal...@mozilla.com>wrote:
>
>> I was thinking not. The dot operator should still have special name
>> lookup rules: it searches through associated impls and all traits in scope.
>> It cannot call anything that is not attached to an impl.
>>
>> This does make functions and methods somewhat less unified, but it makes
>> methods feel more like OO methods from a scoping POV. I feel the draws of
>> methods are not only that they switch the order of the receiver and action
>> but also that they allow functions associated with a type to be called
>> without explicitly importing their names.
>>
>
> Aha. That's exactly the thing I don't like, and thought would be
> beneficial to change. It's different from everything else for no great
> reason (is being like OO a great reason?), and carries baggage with warts
> and thorny issues in it. (Needing special language constructs to write
> methods; normal `fn`s feel like second-class citizens; can't selectively or
> rename-import methods; can't write method-syntax functions in a different
> crate without introducing spurious abstraction boundaries; the whole `impl
> T { fn(&self) }` versus `impl &T { fn(self) }` ugliness; traits and generic
> types in paths raise awkward questions; ...)
>
> --
> Your ship was destroyed in a monadic eruption.
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
--
Jerry
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
