As per Additional Semantic Tagging, someone cannot generate complete code for FFIs that explicitly distinguish C pointer types and non-pointer types with the current state of vk.xml. Take this selection of the specification, which shows a member with <type>void</type>* as opposed to something like <type variant="pointer">void</type>*.
<type category="struct" name="VkDescriptorSetLayoutCreateInfo">
<member values="VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_CREATE_INFO"><type>VkStructureType</type> <name>sType</name></member>
<member>const <type>void</type>* <name>pNext</name></member>
<member optional="true"><type>VkDescriptorSetLayoutCreateFlags</type> <name>flags</name></member>
<member optional="true"><type>uint32_t</type> <name>bindingCount</name><comment>Number of bindings in the descriptor set layout</comment></member>
<member len="bindingCount">const <type>VkDescriptorSetLayoutBinding</type>* <name>pBindings</name><comment>Array of descriptor set layout bindings</comment></member>
</type>
FFI generators for other languages would have to inspect CDATA immediately following <type> children of <member> elements or seek out a p-prefix to detect use of pointer types. This makes things harder, and I think an attribute should clarify how a member type is decorated such that an FFI binding stays in sync with generated C code
As per Additional Semantic Tagging, someone cannot generate complete code for FFIs that explicitly distinguish C pointer types and non-pointer types with the current state of
vk.xml
. Take this selection of the specification, which shows a member with<type>void</type>*
as opposed to something like<type variant="pointer">void</type>*
.FFI generators for other languages would have to inspect CDATA immediately following
<type>
children of<member>
elements or seek out ap
-prefix to detect use of pointer types. This makes things harder, and I think an attribute should clarify how a member type is decorated such that an FFI binding stays in sync with generated C code