Syntax `object.method` (without parentheses) is unused

[petrochenkov]

struct S;

impl S {
    fn f(self) {}
}

fn main() {
    let s = S;
    let f = s.f; // error: attempted to take value of method `f` on type `S` :(
}

It's a valuable piece of syntax and it would be a shame not to put it into action some day.
Any plans/ideas how to do it better?

Several variants I can think about:

1. A method with bound self argument

   let f = object.method; // returns a closure
   

   is equvalent to

   let f = |args...| { object.method(args...) }
   

   Swift goes this route. C# also allows converting object.method to a delegate, although explicitly.
   This is probably the most intuitive variant, but, frankly, I think it's pretty useless in practice (or at least rarely useful).

2. A variant of UFCS

   let f = object.method;
   

   is equvalent to

   let f = typeof(object)::method;
   

   or

   let f = typeof(object)::with_adjustments::method;
   

   I'm not sure how useful is this. UFCS with adjustments (ref, deref, unsize etc.) would be pretty useful, it would allow libraries to evolve more freely (see Vec: looks like is_empty and len are not needed rust#26980 for example of what libraries can't do now if they want to keep backward compatibility), but it doesn't strictly need a value (object), only a type (Object). I don't recall any language doing this.

3. Parentheses elision

   let f = object.method;
   

   is equvalent to

   let f = object.method(); // errors as usual if >0 arguments are required
   

   This is what D does. Parentheses elision greatly reduces symbolic noise in typical code, but can
   probably be confusing sometimes (I don't use D and don't know how confusing it is in practice) and
   some corner cases (what happens if method returns an object implementing Fn?) had to be clarified.

---

Another useful unused syntax, somewhat opposite to object.method is "field UFCS": Object::field.
It would be really great to make Object::field a projection function fn(Object) -> FieldType:

objects.iter().map(Object::field); // Does the obvious thing

However, ownership, i.e. the choice between fn(Object) -> FieldType, fn(&Object) -> &FieldType and
fn(&mut Object) -> &mut FieldType should be taken into account somehow.

[ftxqxd]

Unfortunately, this would probably be backwards incompatible, as fields can share names with methods:

struct Foo {
    frob: &'static str,
}

impl Foo {
    fn frob(&self) -> &'static str { "bar" }
}

fn main() {
    let foo = Foo { frob: "foo" };
    println!("{}", foo.frob);   // foo
    println!("{}", foo.frob()); // bar
}

[petrochenkov]

@P1start
Yeah, I know, but I don't think it's a backward compatibility problem - in case of conflict a field still can be preferred for object.method and a method can be preferred for Object::field, just like now.

[gnzlbg]

@petrochenkov any plans to pursue this?

I've wanted this way too often and might fit in the 2017 roadmap of improving ergonomics.

@oli-obk mentioned in IRC: "just prefer object.field over object.method if both field and method have the same name"

[petrochenkov]

@gnzlbg

I've wanted this way too often

What exactly - variant 1, variant 2, variant 3 of object.method, or Object::field or both?

[oli-obk]

My vote is for variant 1, the others are confusing. Static method lookup should only occur with types and modules, not with bindings.

[gnzlbg]

@petrochenkov variant 1. Simple things should be simple. One can just pass a function as an argument, the same should be easily possible for object methods. Having to create a closure is an inconvenience when the compiler can do it for you. No need to think about move || vs || nor the number of arguments of the closure. When this is required often, the current best solution is to create a let binding to a closure in the enclosing scope. We can do better.

[petrochenkov]

@gnzlbg @oli-obk
Could you write an RFC draft then (with motivation, etc)?
I'm really bad (and slow) at writing texts, but I can do a technical review before it's submitted.

[strega-nil]

I'd like to express my support for variant 1; seems like a nice bit of sugar :)

[gnzlbg]

So I wrote a [Pre-RFC] Unify bindings to callables in internals. In a nutshell it says that a binding to a callable always return a closure, and when the callable is of the form object.method, that closure has an environment that captures the object. This basically makes bindings to all callables work "as one wold expect", that is, the binding accepts the same arguments that the original callable would have accepted if it were used instead.

The main difference with variant 1, is that it also adds the possibility of binding associated functions using object.associated_function that desugars into an environment-less closure |args...| Deduced::associated_function(args...).

(note: since closures without environment work as function pointers, everything should just work)

EDIT: i've removed the associated function syntax from the RFC.

[nagisa]

My vote is against them all :)

1. Borrows or moves object despite fn(*) -> * being a Copy otherwise. Very counter-intuitive.
2. Why not… just use UFCS? There’re also ambiguity issues with typeof(object)::method in generic contexts.
3. Ewww.

[petrochenkov]

@nagisa

Why not… just use UFCS?

UFCS doesn't do adjustments.
You can't turn |vec| vec.slice_method() into Vec::slice_method because Vec itself doesn't have slice_method, it's only accessible through deref.

I agree though, object.method is not the best syntax for "UFCS with adjustments".

[gnzlbg]

@nagisa

Borrows or moves object despite fn(*) -> * being a Copy otherwise. Very counter-intuitive.

How do you create a callable to an object's method, that takes the same arguments as invoking the method through the object (object.method(args...)), without borrowing the object, to obtain a Copy fn(*) -> *? You could probably use an unsafe raw pointer for that, but... that's unsafe.

[nagisa]

@gnzlbg I suppose our expectations for what this ought to behave like differ. I feel like object.method making a binding is significantly different from what similar syntax already does. struct A { f: fn(Self, ...) -> ... }; let a = A { ... }; a.f for example will not cause a borrow or move to happen, because a.f is a plain function pointer that’s Copyable.

Option 1 is basically a proposal to add a different context-sensitive (something that would “activate” if there was impl A { fn f(self, ...) -> ... { ... } and no field with same name) meaning to a.f which returns something resembling a function pointer, but not quite, while also borrowing or moving the a.