Repository: flutter
Issue: Consider using `VULKAN_HPP_TYPESAFE_CONVERSION`
Labels: engine,c: proposal,P3,team-engine,triaged-engine

Here's my understanding of `VULKAN_HPP_TYPESAFE_CONVERSION`:

- When targeting 64-bit, implicit conversion of vulkan handles is typesafe. As a result, `VULKAN_HPP_TYPESAFE_CONVERSION` is enabled by default.
    - `VULKAN_HPP_TYPESAFE_CONVERSION` is automatically enabled when `VK_USE_64_BIT_PTR_DEFINES` is set. The latter is only set when [defines like](https://chromium.googlesource.com/external/github.com/KhronosGroup/Vulkan-Headers/+/5a5c9a643484d888873e32c5d7d484fae8e71d3d/include/vulkan/vulkan_core.h#30) `__x86_64__` are set by the compiler.
- When targeting 32-bit, `VULKAN_HPP_TYPESAFE_CONVERSION` is not set.
- When targeting 32-bit, turning on `VULKAN_HPP_TYPESAFE_CONVERSION` is not typesafe. But it can be turned on anyway.
- `VULKAN_HPP_TYPESAFE_CONVERSION` triggers the generation of *some code*.
    - When targeting 32-bit, this code causes a "conditional expression is ambiguous" when a vulkan handle and a `VK_NULL_HANDLE` is used in a ternary expression. Before https://github.com/flutter/engine/pull/51285, this can be reproduced by setting `VULKAN_HPP_TYPESAFE_CONVERSION` to the `:vulkan_headers_config` [here](https://chromium.googlesource.com/external/github.com/KhronosGroup/Vulkan-Headers/+/5a5c9a643484d888873e32c5d7d484fae8e71d3d/BUILD.gn#10)
    - https://github.com/flutter/engine/pull/51285 allows the GN build to compile successfully both with and without `VULKAN_HPP_TYPESAFE_CONVERSION`
- Internally, `VULKAN_HPP_TYPESAFE_CONVERSION` is set unconditionally whether we're targeting 32-bit or 64-bit platforms (see details in b/328355475).

Here is what the [vulkan docs](https://github.com/KhronosGroup/Vulkan-Hpp/blob/main/README.md#cc-interop-for-handles) say:

> On 64-bit platforms Vulkan-Hpp supports implicit conversions between C++ Vulkan handles and C Vulkan handles. On 32-bit platforms all non-dispatchable handles are defined as `uint64_t`, thus preventing type-conversion checks at compile time which would catch assignments between incompatible handle types. Due to that Vulkan-Hpp does not enable implicit conversion for 32-bit platforms by default and it is recommended to use a `static_cast` for the conversion like this: `VkImage = static_cast<VkImage>(cppImage)` to prevent converting some arbitrary int to a handle or vice versa by accident. If you're developing your code on a 64-bit platform, but want compile your code for a 32-bit platform without adding the explicit casts you can define `VULKAN_HPP_TYPESAFE_CONVERSION` to 1 in your build system or before including `vulkan.hpp`. On 64-bit platforms this define is set to 1 by default and can be set to 0 to disable implicit conversions.

The goal for this issue would be to better align the internal build with the GN build here so that errors can be surfaced before they roll in. We could either:

- Set `VULKAN_HPP_TYPESAFE_CONVERSION` for the GN build
- Make the `VULKAN_HPP_TYPESAFE_CONVERSION` setting internally conditional on whether the build is targeting 32-bit or 64-bit

All this is quite new to me, but it seems like the latter would be better for better type safety. This might take more effort to push through depending on whether there are other vulkan clients that are depending on the current behavior though.

cc @chinmaygarde