1

Any parameter of an enumerated type must be a valid enumerant for that type.

Sentence feels confusing. Probably means "any argument". Even so the sentence feels weirdly formed; it misses verbs or something and partly redundant to the next sentence, and the "of that type" seem partly redundant to the first bullet point.

---

2

Rules do not cover functions without dispatchable handle, such as vkCreateInstance. This impacts use of VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR, enumerants usable in the pNext chain, and potential new enumerants in the VkAllocationCallbacks structure.

---

3

suffixed with _MAX_ENUM¹.

The "¹" points nowhere now.

---

4

it was added by a core version that is supported (as reported by vkEnumerateInstanceVersion)

That is slightly incorrect. Many enumerants were added by core version 1.0, and such version cannot be queried by vkEnumerateInstanceVersion. There seem to be a Querying Version Support chapter, so I suggest linking to that, and improving that chapter.

---

5

If the enumerant is used in a function that has a VkPhysicalDevice object as its first parameter

This seem incorrect for vkCreateDevice (something like #1540).

BTW, I think functions in Vulkan are generally called "commands".

---

6

it was added by a core version that is supported by that device (as reported by VkPhysicalDeviceProperties::apiVersion);

missing "or"

It seems insufficient, and contradictory to the Valid Usage for Newer Core Versions, which says:

Physical-device-level functionality or behavior added by a new core version of the API must not be used unless it is supported by the physical device as determined by VkPhysicalDeviceProperties::apiVersion and the specified version of VkApplicationInfo::apiVersion.

---

7

it was added by an instance extension that was enabled for the instance; or

Probably should be explicit which "the instance".

---

8

it was added by a device extension that is supported by that device.

Should say "physical device".

This seems incompatible with Vulkan 1.0 without VK_KHR_get_physical_device_properties2, which only permit use of enumerants added by instance extensions. Not sure if all extensions list these as dependency. Hypothetically, there could be an extension where use of its physical-device level commands is non-essential, therefore it does not list these dependencies.

---

9

If the enumerant is used in a function that has any other dispatchable object as its first parameter and either:

Brittle in case there is ever an instance-level handle added.

---

10

it was added by a core version that is supported for the device (as reported by VkPhysicalDeviceProperties::apiVersion); or

same as 6

---

11

it was added by a device extension that was enabled for the device.

Should say which device, similarly to 7. Since we have not even mentioned any device earlier, there is no "the device".

---

12

Any enumerated type returned from a query command or otherwise output from Vulkan to the application must not have a reserved value. Reserved values are values not defined by any extension for that enumerated type.

This is slightly confusing, since enumerants are being added all the time. It is not clear which values exactly are reserved at any given time. Based on the latest publicly released spec? Or in the patch version the driver reports (if it reports it)?

---

Most of it feels highly repetitive, and I feel the Valid Usage for Extensions and Valid Usage for Newer Core Versions sections should do the heavy lifting here. The same rules will apply for all the other non-enum entities too.