Re-introduce support for std::expected fixing issue #2375

[MattGuerrette]

This PR re-inroduces support for std::expected as a ResultValueType to fix #2375

[CLAassistant]

All committers have signed the CLA.

[asuessenbach]

Thanks for providing this little PR to re-introduce support for std::expected.

But both files you've modified, vulkan.hpp and vulkan_hpp_macros.hpp, are generated files. You would need to make those changes in snippets/ResultValue.hpp and snippets/MacrosHppTemplate.hpp, respectively, and generate those two files.

Moreover, I think it needs to be a bit more complex. For example, there are functions with more than just VK_SUCCESS as a success code. vkGetEventStatus, for example, has VK_EVENT_SET and VK_EVENT_RESET as success codes. I think, with your change, those values would be handled as unexpected, isn't it?

[MattGuerrette]

@asuessenbach Device::getEventStatus does not seem to use ResultValueType at all and just returns Result, so I dont expect any changes needed there. Am I missing something?

I've updated the PR to remove the manual editing of the vulkan.hpp and vulkan_hpp_macros.hpp and edited the snippets instead. Is it usually required to also run the generator and update the vulkan headers are part of check-in? or would that be done anyway as part of a release? The reason I ask, is that i don't see any hard restriction on clang-format versioning so if individual contributors are running the codegen, that will result in a buch of different commits with different formatting of these generated files creating a lot of noise. I'd expect you want either the project lead or an automated build action to be the one to actually generate and commit the updated vulkan headers.

Let me know if this needs anymore changes.

Thanks 😄

[asuessenbach]

Is it usually required to also run the generator and update the vulkan headers are part of check-in?

Yep, that would be great.

[asuessenbach]

The reason I ask, is that i don't see any hard restriction on clang-format versioning

You're right. Up to now, that hasn't been a big issue, though.
That said, it would be great if you could use some 18.x version of clang-format.

[MattGuerrette]

@asuessenbach Okay, I've generated the vulkan.hpp and vulkan_hpp_macros.hpp headers using VulkanHppGenerator and clang-format 18.1.7

[asuessenbach]

That is, the type is either VULKAN_HPP_EXPECTED<T, Result> or ResultValue<T>, mostly depending on the C++ version?
Do those two types look similar enough, that your compiler won't realize a difference where that type is actually used? If not, your code base would fail when switching to C++23.
That is, maybe you need some additional VULKAN_HPP_USE_STD_EXPECTED, or so, as an additional guard in snippets/MacrosHppTemplate.hpp?

[MattGuerrette]

Sure, I've added VULKAN_HPP_USE_STD_EXPECTED which now needs to be defined before including vulkan hpp headers to enable use of std::expected type. Otherwise it falls back to using ResultValue

[asuessenbach]

And finally, that VULKAN_HPP_USE_STD_EXPECTED should be mentioned as an option in CMakeLists.txt and the README.md.

[MattGuerrette]

Done