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

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 https://github.com/rust-lang/rust/pull/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.

The issue names no files, tests, or implementation entry points. Start by reading the proposed bound-method, UFCS, and parentheses-elision alternatives, along with the field-UFCS discussion; done requires a settled design and explicit acceptance criteria before implementation can begin.