This happens in https://github.com/rust-lang/rust-analyzer/blob/7011094/crates/ide-assists/src/utils/suggest_name.rs#L135.

@rustbot claim

@kpreid How do you think it would be better to handle this situation?

use std::slice::Iter;

struct Foo;

impl From<Foo> for fn(&Iter<'_, i32>) -> *mut i32 {
    fn from(_: Foo) -> Self {
        todo!()
    }
}

@Lampese I guess what he wants is that if Self is a path type, the variable name is the type name, otherwise fall back to from.
But personally, I think it is not conducive to unified management.

Yes. Things like this can never be perfect; they can only handle common cases better.

Speaking of common cases, here's another one not using the From trait at all:

struct Foo {}
struct Bar {}
impl Bar {
    pub fn from_foo(_: Foo) -> Self {
        Self {}
    }
}
fn do_something(_: Bar) {}

fn main() {
    let foo = Foo {};
    do_something(Bar::from_foo(foo));
    //           ^^^^^^^^^^^^^^^^^^ select this and extract into variable
}

This generates the variable name from_foo, but, similarly, bar would usually be better. Since from_* constructor functions are part of Rust idiom, I think it would be good if rust-analyzer recognized those too, in the same way. That is, if there is a call of the syntactic form *::$1::from_*(*) or *::$1::from(*), and $1 is a type name, then $1 should be (snake-cased and) used as the suggested variable name. No need to care whether the From trait is involved at all.

with_ seems like a reasonable addition to this to be handled in the same way as from_