<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, Jul 19, 2015 at 9:58 PM Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">No, this makes me even more concerned.<br></div><div style="word-wrap:break-word"><div><br></div><div>The entire original reason for the C API is to provide a stable interface for people who didn’t want to chase the C++ API (or didn’t want to chase *as much* of it).</div></div></blockquote><div><br></div><div>That may be the original reason, but it is not currently the only reason why people are using the C API today.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>  In this sense, I consider the LLVM C API to be unlike the other “bindings” for generating IR: its purpose is to remain stable, not to be a language binding for people who prefer to write things in C.</div></div></blockquote><div><br></div><div>While that may have been the original intent, one of the other usages of the C APIs today are simply to provide access to the C++ APIs from languages which have C FFIs. For example, OCaml and Go both have bindings in those languages built on top of the C bindings.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>If your claim is that the C API is too restrictive and prevents C++ evolution, then we just need to be careful about what we add to the C API.</div></div></blockquote><div><br></div><div>I agree. However, this desire is in tension with the desires of those that see these as bindings for the C++ APIs to mirror each and every change in the C++ APIs in order to access them from other language.</div><div><br></div><div>Increasingly, I think that our current design of the C APIs have been overly influenced by the needs of these users. As a consequence, I think we have let a great deal enter the C API that isn't really reasonable for a stable and very long-term API.</div><div><br></div><div>As it stands today, I think that outside of libLTO and libClang, the LLVM C API is more suitable as a set of non-stable bindings than as a stable C interface to LLVM's core functionality. I also think that this use case is a real and legitimate one. As such, I think that it would be a positive change to turn the current C API into an *explicit* set of bindings that have exactly as much API stability as the C++ APIs do. This would mean that ToT would change freely, and minor releases would remain stable.</div><div><br></div><div>But I also completely agree with your view on how a *stable* C API should be designed, and I also think *that* is a useful thing. I just don't think we have a remotely good design for it today. I think designing such a stable API would be a big and useful project for someone to undertake. I have some ideas about how to do it in a way that would both be useful and usefully stable, but I think it would look very different from the current C API.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>  Splitting it out to another project would not address this concern anyway, unless what you’re really saying is “we can break the C API even though it is trying to be stable, because its an external project”.</div></div></blockquote><div><br></div><div>I also don't really see why a separate project helps. Maybe it would help for the design of a stable API for use by JIT-ing consumers or frontends would best start as separate project where it could evolve some before stabilizing? Unsure if that's useful or necessary. <br></div></div></div>