gchatelet added a comment. >> Thx for letting me know @foad . I'll make sure to keep the old API with a >> deprecation message from now on. >> Do you have any other suggestions on how to make this less painful for >> out-of-tree users? I'm afraid that the cleanup phase (removal of deprecated >> function) will be disruptive as well. > > Removing deprecated functions is generally OK, as long as it happens *after* > the preferred function is introduced, so we have time to switch over.
Sure. My apologies for this. > In the specific case of functions taking `Align` instead of `unsigned`, > perhaps you could start off allowing implicit conversion from `unsigned` to > `Align` and then remove it later, when all callers have been updated? Or > perhaps it's too late for that now. I tried but it's not convenient for me to find the call sites that need updating. Also I don't want to introduce regressions by having automatic conversion from `bool` or anything implicitly convertible to `int`. By proceeding like this, I'm making sure that each change is reviewed and that the semantic is correct. When in doubt I try to get a review from the original author. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71213/new/ https://reviews.llvm.org/D71213 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
