Consider boxing errors more

[HadrienG2]

Clippy complains about my error enums based on Vulkano error types because they are very large (>= 160 bytes), and thus make Results very expensive to move around if the memcpy is not elided.

I think this is a valid performance concern from clippy's side, as I've observed my fair share of failed move optimizations from rustc/LLVM, and the performance impact that comes with them can indeed be quite significant.

On the other hand, I am also well aware that error boxing come with a large ergonomic hit. Among other things, it reduces ability to pattern match error types, adds annoying Box::new() everywhere, and if applied on the client side it breaks use of ? unless you write all the From<NotBoxedError> impls yourself. The latter is an argument in favor of implementing boxing on the side of the code that throws errors, if it is to be implemented at all.

Overall, I'm a bit torn here, and could use extra opinions from other people. Are you fine with the performance risks of having large results, or would you rather have vulkano do the right thing from the performance PoV even if it comes at some ergonomic cost (and a major error API break if done today)?

[marc0246]

I agree we should box errors on our end, for sure.

[Rua]

I think ValidationError should be boxed, but maybe not the rest.

[marc0246]

Indeed that is what I was referring to as well, to be clear. Even then VulkanError is going to be 16 bytes in size as will Result<Arc<Device>, VulkanError> for instance, as opposed to 104 bytes.