That actually isn’t completely equivalent. With the former example, `invoke::<_>(x)` works, but with impl, `new_invoke::<_>(x)` doesn’t work. This is a deliberate aspect of the design of impl in argument position, and part of the reason why it can be better to avoid it in libraries.
In the case of functions, this difference probably doesn’t matter, because you normally can’t name the type of a function anyway, and are extremely unlikely to wish to; but in other cases being able to type the turbofish can matter for ergonomics.
As an arbitrary example, take std::convert::Into::into: the type parameter is on the trait rather than the method, so you can’t do `x.into::<T>()`, but if you need to constrain the type you must do so otherwise, e.g. `let y: T = x.into();` or `<_ as Into<T>>::into(x)`. (In that case in particular, you’d write `T::from(x)` instead, but there won’t always be such an ergonomic replacement.)
In the case of functions, this difference probably doesn’t matter, because you normally can’t name the type of a function anyway, and are extremely unlikely to wish to; but in other cases being able to type the turbofish can matter for ergonomics.
As an arbitrary example, take std::convert::Into::into: the type parameter is on the trait rather than the method, so you can’t do `x.into::<T>()`, but if you need to constrain the type you must do so otherwise, e.g. `let y: T = x.into();` or `<_ as Into<T>>::into(x)`. (In that case in particular, you’d write `T::from(x)` instead, but there won’t always be such an ergonomic replacement.)