On Sat, Oct 19, 2013 at 10:52 PM, Patrick Walton <[email protected]>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.

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 <[email protected]>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
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to