The benefit of not having the gap is not having to spend a bunch of time and effort on ABI maintenance. I actually left LLVMVectorTypeKind in at first, and was asked to remove it in code review. Then, I left a gap in the enum where LLVMVectorTypeKind used to be and was asked in code review to remove the gap.
We attempt not to break ABI and API, if we don’t need to. It is not an ironclad guarantee, because sometimes things may change so fundamentally on the C++ side, so as to make keeping C API compatibility effectively impossible. But it is “best effort” attempt. I’m sorry you got contrary advice from a reviewer.
As for not exposing the names, I think that would be a mistake.
I’m not sure what you mean by this. I want you to expose the new scalable vector kind as LLVMScalableVectorTypeKind (as you have), and put it at the end of the list to not change existing enum values. I want you to leave the existing C API name LLVMVectorTypeKind as referring to the renamed on the C++ side ‘Type::FixedVectorTyID’.
If, later on, it seems useful to also use the new “FixedVectorType” terminology in the C API, that can be done. When doing so, be consistent, and also rename the constructor from “LLVMVectorType” to “LLVMFixedVectorType”. Additionally, please leave the old names as deprecated aliases. It doesn’t feel to me that such a renaming is really worthwhile, though, and I’d suggest it best to just leave the old names alone.
The whole point of refactoring vector types is to expose the fact that scalable vectors exist and have to be dealt with. If a ScalableVectorType object is handed to you from outside of your code, you need to be able to deal with it. Having the ability to correctly handle a scalable vector and having the ability to create one are two separate things. The C api currently has the first ability but not the second. Adding the ability to construct scalable vectors from C still remains to be implemented. There’s a lot of outstanding work. It all needs to get done, but with limited resources, some tasks will get prioritized over others. I would argue that since support for scalable vectors is still a work in progress, you should probably not be constructing them and passing them into it.
I agree, it’s fine that you haven’t implemented full scalable vector support yet in the C API.
It seems to me that you don’t actually care about constructing scalable vectors (otherwise you’d be asking me to complete the work rather than back it out), so the C api should fully support your use case. You should just update your codebase to correctly handle scalable vs fixed width vectors. That way, when the day comes that LLVM fully supports scalable vectors, you will be ready.
I don’t have a codebase affected by this, I care because users out in the wide world do have such codebases, and we have a policy of not breaking them unless it’s necessary. If you’d like to do more work and fully implement the proper LLVM-C interfaces to support scalable vectors, that’s fine too. But I’m not asking for that, because it would be new functionality, rather than simply not breaking old functionality.