Naming convention for semaphores

I was reading this article https://docs.vulkan.org/guide/latest/swapchain_semaphore_reuse.html and thought it was very helpful, but I think understanding it is harder than it needs to be due to a naming convention issue.

The problem is that semaphores are primitives that are signalled at the end of one operation and waited on before another operation starts. But in the current naming convention all semaphores are named after the operation that signals them. For example, `submit_semaphore` is signalled by `vkQueueSubmit` but from its name it's not clear whether it's waited by `vkQueueSubmit` or is signalled by it, and it's also not clear who waits for that semaphore.

I think it could be made much easier to understand if each semaphore was following a naming convention where both the operation that signals it and the operation that waits for it are in its name, for example `submit_semaphore` becomes `submit_to_present` and `acquire_semaphore` becomes `acquire_to_submit`. Following this convention, it's immediately obvious that acquire does not have a semaphore it's waiting for, that `acquire_to_submit` separates it from submission, that `submit_to_present` separates submission to presenting and that presenting does not signal anything, because there's no semaphore named `present_to_something`.

Note that the same naming convention has proven to work much better for matrices, when `object_to_world` is used instead of `object_matrix`, it also works much better for functions, barriers and other entities that in some sense mediate two other entities but that's another story.