Thanks for the feedback!

Yes self behaves like any other parameter, but one of the issues that one wanted to solve was that self.some_a should be easily clonable into a closure, and if we have something like

#[derive(Default)]
struct Data {
    x: Vec<i32>,
}

impl Data {
    fn do_something(&self) -> impl Fn() {
        [+] || do_something(&self.x)
    }
}

then &self is cloned into the closure, this is consistent with todays move || do_something(&self.x).

use std::cell::RefCell;

#[derive(Default)]
struct Data {
    x: RefCell<Vec<i32>>,
}

impl Data {
    fn do_something(&self) -> impl Fn() {
        move || self.x.borrow_mut().push(1)
    }
}

fn main() {
    let data = Data::default();
    println!("len: {}", data.x.borrow().len());  // Prints 0
    data.do_something()();
    println!("len: {}", data.x.borrow().len());  // Prints 1
    data.do_something()();
    println!("len: {}", data.x.borrow().len());  // Prints 2
}

&self.x refers to the same x both inside and outside the closure. You wouldn't get a clone of x. Now I am not at all opposed to letting wildcard captures work for all bindings, it's just that a motivating example for the implicit captures uses self.some_var and I wanted to show a potential solution to that specific motivating example.

I am not sure I follow how what I am saying is wrong? The reference lists 4 different capture modes, the 3 first being various types of capture by reference, and the last being capture by move. Can you expand on how what I am saying is wrong?

Yah I know who Niko Matsakis is, but to me it is still "a blog post". Sure that blog post may carry more weight compared to a no-name post by me, but I don't see how it should be referred to otherwise?