[RenjiSann]

Closes #15287

[xtqqczze]

I noticed that this PR introduces stylistic changes to generic parameters. Could we first agree on which style we prefer before applying these changes?

trait MyTrait {}
fn foo(a: impl MyTrait) {
    // [...]
}

versus

trait MyTrait {}
fn foo<T: MyTrait>(a: T) {
    // [...]
}

Clippy provides a restriction lint, clippy::impl_trait_in_params, for the former style.

[RenjiSann]

I noticed that this PR introduces stylistic changes to generic parameters. Could we first agree on which style we prefer before applying these changes?

trait MyTrait {}
fn foo(a: impl MyTrait) {
    // [...]
}

versus

trait MyTrait {}
fn foo<T: MyTrait>(a: T) {
    // [...]
}

Clippy provides a restriction lint, clippy::impl_trait_in_params, for the former style.

I'd say let's use the impl syntax when possible (whenever the trait is not composite T: A + B), or if you explicitely need several parameters to reference the same type

[RenjiSann]

@xtqqczze if you prefer, I can use the <T: Trait> syntax everywhere, though I find the other one more readable

[xtqqczze]

I do have a concern that this PR includes a refactoring that converts existing <P: AsRef<Path>> bounds to impl AsRef<Path>. This change might be better handled separately, or at least in a separate commit, to keep the scope of this PR focused.

I don't have a strong preference between the two syntaxes, so I'd be interested to hear what other reviewers think.

[RenjiSann]

@xtqqczze I changed back to the <P: AsRef<Path>> syntax, so we can address the syntax preference issue elsewhere

[xtqqczze]

I think this change would be better handled separately, or at least in a separate commit.

[RenjiSann]

I disagree with this one specifically. This PR is meant to uniformize the interface of AtPath, and I consider uniformizing the syntax of the whole interface to be in scope, whether it is with the impl AsRef<Path> or <T: AsRef<Path>> syntax

[xtqqczze]

If you consider this in scope, the style change should still be made in a separate commit.