David Pedersen

Hm yeah that is a bit of a footgun for sure. I think we could 1. Leave things as is but document it and provide a type that doesn't override...

> Wouldn't it be better to fix this in tower-http? That would require moving axum's `NestedPath` to tower-http or adding something similar there. I'm not a big fan of that....

Converting to draft because I just remember that this (and `NestedPath`) doesn't support path params in the nested path. axum supports `.nest("/:foo", ...)` which this should probably support.

> I'm a bit surprised this is in axum as opposed to axum-extra. Yeah I considered putting it in axum-extra. That probably is the better path. I'll move it. >...

That crate seems to already provide it. I have no plans of adding that to axum itself.

axum has less breaking releases than axum-extra so it more about maturity and long term stability. I still think it’s appropriate for axum to provide a multipart extractor.

Awesome! What are the `rustc-ice-2023-12-30T16_17_52-3660.txt` files for?

> Those are files rustc writes when it crashes with an Internal Compiler Error 😄 Ah I see! I've gotten plenty of ICEs but don't think I've noticed those files...

> I'm skeptical about this change, since it pulls in an extra dependency without actually getting rid of futures-util in the dependency tree. Yep that's true but I suppose one...

> Looks decent, but I'm wondering if we should ship this in 0.7.x. It seems pretty likely that some people are relying on `IntoResponseParts` from a tuple running even if...