UFCS RFC needs to be clearer about method call syntax

[pnkfelix]

RFC PR #132 (UFCS) had many descriptions of various paths, but completely omitted concrete examples of an actual method call (with the receiver expression and the arguments) written via the proposed notation.

In particular, assuming a trait ToStr { fn to_str(&self) -> String } and type S that implements ToStr and also has its own impl S { fn to_str(&self, max: uint) -> String } are we expecting to be able to write:

• fn f(s: &S) -> String { s.ToStr::to_str() }, or
• fn f(s: &S) -> String { ToStr::to_str(s) }, or
• both?

and likewise:

• fn g(s: &S) -> String { s.<S>::to_str(10) }, or
• fn g(s: &S) -> String { <S>::to_str(s, 10) }, or
• both?

(Perhaps the answer is implied by some other document that specifies whether method call expressions use a full path for the method name, or just an identifier and optional generics args list ::<T, U, ...>. Nonetheless this detail is important enough to go into the document itself.)

[pnkfelix]

cc @nikomatsakis

[nrc]

At least the second option for both.

I think the first form should also be allowed since at worse it will be redundant and in some cases could restrict the traits examined in trait matching, whilst still doing dynamic dispatch.

[aturon]

cc me

[pnkfelix]

Another argument for supporting s.ToStr::to_str() and s.<S>::to_str(10) : the other form lacks autoref/autoderef for the receiver s

[nikomatsakis]

The UFCS RFC did not propose any way to use method-call syntax in this fashion. This would be a distinct RFC, I believe.

[Havvy]

Is this still valid?

[pnkfelix]

I’ll review