<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 30, 2015 at 1:04 PM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</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>I think the idea of having a (hopefully not too) fluid C API that can encompass everything people want to be able to do in the language of their choice and calls into LLVM to do work sounds like a great idea. I think it would be useful to expand the number of people who are able to do research and development with LLVM without having to reinvent LLVM. That said, this is directly at odds with our desire to have a stable C API that can be supported long term (as you said at the end of the email). I.e. where do we draw the line on what can or should be added to the C API? What if the people that want the functionality are willing to deal with it being (occasionally) unstable?</div></div></blockquote><div><br></div><div>Yeah, splitting the concerns of API completeness and API stability seems like a good idea. Right now we have clients like llgo that want to generate new debug info, and are perfectly happy to keep up to date with changes. They need a complete API, not a stable API, and our insistence on a stable C API has actually gotten in the way here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I don't agree with you that no one will take the time to design a well thought out C API. We've managed to get a lot of real world experience lately at both how these things will be used, and how we'll maintain such a thing. I think Juergen and others are a good group to come up with an answer to our engineering challenge.</div></div></blockquote><div><br></div><div>Sure, if people are planning to design a stable API that leave LLVM with more flexibility, then I'm all in favor of switching over to it. So far I haven't heard any new suggestions. I think any such design would probably be write-only, and revolve around sharing the bitcode auto-upgrade logic.</div></div></div></div>