[LLVMdev] [RFC] Developer Policy for LLVM C API

[Chandler Carruth]

On Sun, Jul 19, 2015 at 9:58 PM Chris Lattner <clattner at apple.com> wrote:

> No, this makes me even more concerned.
>
> 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).
>

That may be the original reason, but it is not currently the only reason
why people are using the C API today.


>  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.
>

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.


> 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.
>

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.

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.

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.

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.

 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”.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150720/131249b8/attachment.html>