Drop prefix vk

[porky11]

All variables starting with vk or VK_ that are already in package vk should be renamed.
vk.SUCCESS instead of vk.VK_SUCCESS and vk.createImage instead of vk.vkCreateImage etc.

[SimonDanisch]

That's a fair suggestion! There is value in having a 1:1 mapping of the C-API, but since we don't export any functions, it might be nicer to just drop the VK.

[Gnimuc]

How about remove the vk module(export every thing including functions)?

At the first glance, the vk module somehow looks like the cl module in OpenCL.jl, but OpenCL.jl is not as low-level as VulkanCore.jl, it has some abstractions. I guess that's why it merely exports the cl module, which implies its API is a little bit different than the original OpenCL C-API.

To me, this package serves as an one-to-one correspondence of the Vulkan C-API, I guess there is no harm in exporting everything out: ModernGL.jl exports every gl* function and GL* constant, and it works fine. Any abstraction should go into more high-level packages like Vulkan.jl.

[porky11]

If you want no abstractions, you shouldn't use a package for the new functions.
Rusts unsafe opengl lib also uses a package gl, and removes prefix from the functions and constants

[serenity4]

I agree with @Gnimuc. Personnally, I just use VulkanCore.vk directly, because typing in the vk. each time is annoying (especially for all those enums!). If one wants to keep it that way, then

import VulkanCore
const vk = VulkanCore

seems an acceptable solution to me. As for dropping the vk/Vk/VK_ prefix, I also believe that it would better be done inside Vulkan.jl. The main reason would be, in addition to being a 1:1 correspondence with the Vulkan API, that it is easier to define new symbols that don't have this prefix as a higher abstraction (e.g. to wrap a VkInstance, IMHO Instance would be a fitting name).

[serenity4]

I think we agree that for such a core/low-level package, keeping the prefixes makes sense, so I'll close this.