+   /**
+    * @param Product[] $products
+    */
    #[Route(path: "/products", methods: "POST")]
    public function __invoke(
-        #[MapRequestPayload(type: Product::class)] array $products,
+        #[MapRequestPayload] array $products,
    ): Response {
    }

Honestly, when you mentioned this feature during the type option discussion, I had higher expectations. But now that I see the diff, I’m not so sure. The combination of attributes and PHPDoc has always bothered me—things like the duplication of argument names like $products, the need for additional dependencies to make it work, and possible performance drawbacks with the current implementation make me question if it’s really worth it...

I get your concern, yet that phpdoc is needed anyway for type detection in IDEs/static analyzers to work.
So we actually end up duplicating that type information in a Symfony-specific way, that's what make me think it is worth it.

I don't think the deprecation is needed nor desired

Not strictly needed indeed but: it's not obvious what$type is about, anything else than arrays are auto detected through type declarations. That makes the API rather confusing IMHO, only for a special case that this PR is going to handles pretty much 100% of the time (#[MapRequestPayload requires serializer which requires type-info). Unneeded complexity to me. Still not convinced?

This adds advanced type resolution to the hot-path, while this info might not be used; we should look for a way to make this parsing lazy

👍 I will wrap that logic in a closure and pass it to ArgumentMetadata::$type for late execution

Still not convinced about the deprecation :)