<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Aug 16, 2015 at 10:34 PM, deadal nix via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2015-08-16 21:51 GMT-07:00 Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span>:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>The promise of stability. We don't promise that the C++ API will stay stable.</div></div></div>
</blockquote></div><br><br></div></div></div><div class="gmail_extra">Why was that promise be made in the first place ? Has it been made in the first place ?<br></div></div></blockquote><div><br></div><div>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. :)</div><div><br></div><div>There are really three goals here: flexibility to change LLVM IR, completeness of the C API, and stability of the C API. Pick two.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div>