Add explicit return type to funcpointer definitions in Vulkan XML

[mematthias]

Proposal: Explicit return types for funcpointers

Currently, it is not possible to fully analyze function pointer signatures in the Vulkan XML in a purely static way.
While the function arguments and the function name are accessible, the return type is not.
This makes it difficult to parse function pointers reliably in generators and analysis tools.
Additionally, the missing return type makes it very hard to construct a proper topological order of type dependencies, since the dependency chain cannot be resolved statically.

Suggested change

The requires attribute of the <type> element could be used to store the return type explicitly.
At the moment, the requires attribute is only used for redundant information that can already be derived from the function arguments.
Using it consistently for return types instead would remove this redundancy and make the return type available in a static, machine-readable way.

For example:

<type category="funcpointer" requires="VkBool32">typedef VkBool32 (VKAPI_PTR *<name>PFN_vkDebugUtilsMessengerCallbackEXT</name>)(
    <type>VkDebugUtilsMessageSeverityFlagBitsEXT</type>           messageSeverity,
    <type>VkDebugUtilsMessageTypeFlagsEXT</type>                  messageTypes,
    const <type>VkDebugUtilsMessengerCallbackDataEXT</type>*      pCallbackData,
    <type>void</type>*                                            pUserData);
</type>

With this change, the return type, arguments, and function name can all be determined statically and unambiguously.
It would also make it possible to construct a correct topological ordering of all types.

Alternative option

If using requires for return types is considered semantically unclear, a dedicated returns attribute could be introduced to make the intent explicit (at the cost of a schema extension).

Summary

• Problem: Return types of funcpointers cannot currently be determined statically
• Proposal: Use requires to specify the return type explicitly
• Alternative: Introduce a new returns attribute for stronger semantic clarity