I disagree; type safety is something that is missing from almost every C api I've used; you end up with opaque handles that are just integers that can be easily misused. Consider the glBufferSubData method [0] - 2 of 4 of those parameters are really just integers that the programmer needs to know about, that the compiler won't check,and the last two are tightly coupled and not type safe; thetes nothing stopping you from passing an array of doubles (or whatever pointer you have lying around).
Opengl also gets away with because you're almost always working with either floats or integers (for say index buffers) but once you start dealing with containers of containers, a C api ends up really messy with everything being an "object" and having to call function_str(my_obj_handle) with the correct handle - see sentry's api [1] for an example of what this looks like.
A C++ api for OpenGL would allow for type safe flags, type and bounds checked buffers, RAII handles with all the good (and granted, bad) that comes with them.
It seems like you don’t consider requirements like ABI at all. There’s a reason for opaque handles (typeless pointers or integer handles).
When managing resources on separate memory, RAII is also rarely something you’d want. There are different memory management strategies and tight control over memory is very important.
Even if you implement your library in C++ you will need to expose a C API to be compatible with other languages. Not everyone uses C++.
> When managing resources on separate memory, RAII is also rarely something you’d want.
It's the opposite.
When managing resources in system memory, RAII is rarely something I’d want because malloc() is slow.
When managing resources on separate device, RAII is invaluable. These external resources often have API designed like bind/use/unbind, map/update/unmap and similar. You forget that one close/unbind/unmap and you violate your part of the contract i.e. anything may happen including crashes and memory leaks.
Opengl also gets away with because you're almost always working with either floats or integers (for say index buffers) but once you start dealing with containers of containers, a C api ends up really messy with everything being an "object" and having to call function_str(my_obj_handle) with the correct handle - see sentry's api [1] for an example of what this looks like.
A C++ api for OpenGL would allow for type safe flags, type and bounds checked buffers, RAII handles with all the good (and granted, bad) that comes with them.
[0] https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/gl...
[1] https://github.com/getsentry/sentry-native