Enumerant validity rules seem incorrect

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.

Start by reviewing the enumerant validity rules, the Querying Version Support chapter, and the Valid Usage for Extensions and Valid Usage for Newer Core Versions sections referenced in the issue. Check the cited Vulkan commands and handle cases against the specification wording. Done means the rules are resolved consistently, references are accurate, and the obsolete footnote and wording issues are addressed.

Written by the indexing model from the issue text.