[llvm-dev] [LLVMdev] [RFC] Developer Policy for LLVM C API

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Mon Aug 17 09:55:13 PDT 2015

On 08/17/2015 08:34 AM, Reid Kleckner via llvm-dev wrote:
> On Sun, Aug 16, 2015 at 10:34 PM, deadal nix via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>     2015-08-16 21:51 GMT-07:00 Eric Christopher <echristo at gmail.com
>     <mailto:echristo at gmail.com>>:
>         The promise of stability. We don't promise that the C++ API
>         will stay stable.
>     Why was that promise be made in the first place ? Has it been made
>     in the first place ?
> It sounds like you're in favor of dropping C API stability then, if 
> it's holding us back? That feedback is actually really helpful. :)
> There are really three goals here: flexibility to change LLVM IR, 
> completeness of the C API, and stability of the C API. Pick two.
> The goals are mutually incompatible and we have to trade off one for 
> the other. Most of the LLVM core developers value goal #1, the ability 
> to change the IR. Look at the pointee type changes that David Blaikie 
> is working on, and the new EH representation. If we promise both 
> stability and completeness, these things are impossible.
> One way forward is to guarantee stability, but limit completeness. 
> This would mean limiting the C API to constructs that will always and 
> forever be easily represented in LLVM.
> The other choice is to forget stability and wrap the C++ API 
> completely, potentially with something auto-generated. We could make a 
> more limited stability promise along the lines of "these APIs will be 
> updated to reflect changes to the IR, and are otherwise stable." I 
> think everyone would be fine with that.
In particular, such an API would be a good start to the "unstable" API 
which has been discussed.  If you wanted to use the opportunity to 
introduce such a thing, I'd be in support.  Put it in a different 
directory for now, but if we decide to merge the current C API into the 
unstable grouping, we'll combine them at some point.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org         http://llvm.cs.uiuc.edu
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150817/365964bf/attachment.html>

More information about the llvm-dev mailing list