Open
Description
🚀 The feature, motivation and pitch
Thank you for all your hard work on PyTorch and LibTorch! The C++ API is excellent, but there’s a recurring need across many developer communities for an official or semi-official C API (i.e., a stable libtorch_c.so / “C shim”).
Why a C API?
Language Interop: Most languages (Go, Rust, Nim, D, Julia, R, etc.) have straightforward foreign function interfaces to C but not necessarily to C++ with templates/exceptions. An official C layer would dramatically simplify and standardize these bindings.
- Stability: A C API can be versioned more predictably and avoid name-mangling or ABI mismatches. This reduces the maintenance burden on community wrappers that rely on private or auto-generated bindings.
- Ecosystem Expansion: With a stable C library, more open-source contributors could create robust, long-lived libraries in many different languages without reinventing a custom “C++ → C → X Language” layer each time.
Proposed Approach
- Minimal, Carefully Designed C API: Provide a stable subset of tensor creation, basic ops, module loading, forward passes, etc. The full C++ feature set isn’t necessary initially.
- Officially Documented & Versioned: Offer minimal but clear function signatures, guaranteed not to break across patch/minor releases.
- Built/Distributed Alongside LibTorch: So that developers can do -ltorch_c or similar, just as they do for -ltorch.
Potential Impact
- Ease of Development: By lowering the complexity of bridging languages, new communities can adopt PyTorch with less friction.
- Reduced Maintenance for the Core Team: While it might be some up-front work, a stable C layer cuts down on repeated bug reports/issues from “unofficial, hacky” C++ wrappers that break each release.
- Wider Adoption: A formal C API can accelerate usage of PyTorch in more domains and languages where official support is lacking.
Alternatives
No response
Additional context
No response
cc @jbschlosser