[PATCH] D114860: [llvm-c] Make LLVMAddAlias opaque pointer compatible

Wed Dec 1 14:24:22 PST 2021

dblaikie added a comment.

In D114860#3165439 <https://reviews.llvm.org/D114860#3165439>, @CodaFi wrote:

>> I think deleting functions with proper alternatives is fine, probably one at a time though so people can work through updating calls to those functions.
>
> This is not, and has never been, the policy for deprecation for C API functions. We have a strict policy of ABI compatibility (for better or for worse) in these C bindings, these functions must stay.
>
> Now, am I saying this is a good thing: absolutely not. I think this policy makes very little sense and we ought to get it changed. There's just not much will to do so at the moment.

Like, at some point, these functions are going to be removed because it won't be possible to express them anymore - pointer types won't carry the necessary information. So it's not a question of if, but when.

In D114860#3165103 <https://reviews.llvm.org/D114860#3165103>, @nikic wrote:

> @dblaikie To be clear, I'm not talking about the API replaced here, but about APIs that had an opaque pointer compatible version for many years now. I agree that there should be time between adding the replacement API and removing the old one.

Ah, sure - if something's been attributed as deprecated with a new alternative and had at least a release and it's going to be removed eventually, I'm OK with it being removed then. (I wouldn't argue that it /has/ to be attributed as deprecated for at least a release - if it's just in the release notes but doesn't have the attribute, someone could twist my arm into convincing me that it's still had enough opportunity for migration - but I'd prefer the attribute to go in whenever the new alternative API goes in anyway)

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114860/new/

https://reviews.llvm.org/D114860