Make AsyncFnOnce, AsyncFnMut, AsyncFn non-#[fundamental]

[steffahn]

Address the issue #136723 on nightly (the issue will only actually be fixed with a beta backport).

[rustbot]

r? @cuviper

rustbot has assigned @cuviper.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[steffahn]

r? @compiler-errors

[compiler-errors]

(the issue will only actually be fixed with a beta backport)

I'll beta-nominate this and it should be a no brainer to accept, but I'd like to temper a sense of urgency here by making sure it's overwhelmingly it clear that anyone who would take advantage of this in coherence between 1.85 and when this would be landing "naturally" in 1.86 would be doing it almost certainly maliciously, on purpose, rather than just doing it accidentally, lol.

@bors r+ rollup

[bors]

📌 Commit 7155382 has been approved by compiler-errors

It is now in the queue for this repository.

[steffahn]

Where’s the bors r+ speedrun 😎 leaderboard?

[steffahn]

anyone who would take advantage of this in coherence between 1.85 and when this would be landing "naturally" in 1.86 would be doing it almost certainly maliciously, on purpose

Not necessarily, I think it could very reasonably appear naturally. After all, Box<dyn FnOnce() -> BoxFuture<()>>; can be a natural choice for “simulating” a Box<dyn AsyncFnOnce()>, and then it can be a reasonable idea to desire an API that’s able to accept both, either any impl AsyncFnOnce(), or a Box<dyn FnOnce() -> BoxFuture<()>> value.

A workaround that’ll still be okay is to use some struct DynAsyncFnOnce(Box<dyn FnOnce() -> BoxFuture<()>>); instead, the local struct supports the negative reasoning again. This is not problematic either, because DynAsyncFnOnce won’t be implementing FnOnce either…

…which also demonstrates that any stabilizing a way to implement FnOnce for custom structs can be problematic in this regard (once again breaking future-compatibility of a Fn*∪AsyncFn* unification).

Also any stabilizing a way of doing/using dyn AsyncFnOnce trait objects could come with the analogous issue with reversed roles, that FnOnce’s #[fundamental]ity means Box<dyn AsyncFnOnce…*> can’t support being changed to implement FnOnce at a later point.