Unified function / method call syntax

[rust-highfive]

Issue by visionmedia
Thursday Jun 06, 2013 at 14:12 GMT

For earlier discussion, see rust-lang/rust#6974

This issue was labelled with: B-RFC in the Rust repository

---

I'm not sure how this would play out with internals or if it wouldn't provide enough information to the compiler, but instead of something like:

impl Shape for Circle {
    fn draw(&self, s: Surface) { do_draw_circle(s, *self); }
}

If possible it would be great to just do something like:

fn draw(self: Circle, s: Surface) {
  // ...
}

Where circle.draw(surface) is just sugar for draw(circle, surface).

[m-bra]

One reason against it would be that when you unify the syntax, you open up the implementation interface of objects. You would not be able to tell wether a function/method is part of the implementation or not. If you see circle.draw(surface) now, you can be sure: this method is implemented for circle, it knows the circle well, i can trust it. It's part of circle. If you have function(circle, bla) you can clearly see that it is not part of the circle implementation. Unifying the syntax would mix functions and methods and may lead to instable APIs.

[target-san]

Sorry for interfering guys.
I personally see no problems with desugaring a.b() into b(a). By thinking 'I can't distinguish functions form methods' you can come to 'I can't distinguish methods of different traits, so let's force user to specify them'.
Though, this specific case can be implemented with some operator, like |>, thus having a|>b().
There's also other approach, C# extension methods. I don't like their idea of 'special' functions. What if I want chaining some ordinary functions?

To conclude, I'm completely for TJ's variant of UFCS. If not, then let's have at least some 'chaining' operator.

EDIT: @m-bra On your worries about sugared free function indistinguishable form method. Rust already has that trouble with extension traits. In fact, this approach (with 'special signature' functions) was used in C#, in a bit different manner.

[alexcrichton]

This has basically all since been implemented, so closing.

[mikepurvis]

@tj @alexcrichton This issue is high in the Google results for queries related to Rust and unified call syntax. Could there be links please added to documentation explaining how it works, please?

[kennytm]

See https://github.com/rust-lang/rfcs/blob/master/text/0132-ufcs.md and https://doc.rust-lang.org/book/ch19-03-advanced-traits.html#fully-qualified-syntax-for-disambiguation-calling-methods-with-the-same-name for what is actually implemented.

Note that we only support calling Circle::draw(circle, surface) or Shape::draw(circle, surface) or <Circle as Shape>::draw(circle, surface), not draw(circle, surface).
Also you cannot define fn draw(self: Circle, surface: Surface) outside of an impl.

[Havvy]

https://doc.rust-lang.org/stable/reference/expressions/call-expr.html#disambiguating-function-calls as well