mirror of
https://github.com/carbon-language/carbon-lang.git
synced 2026-09-24 13:50:10 +01:00
C++ Interop: Mapping std::string_view to Core.Str (#6177)
This proposal defines a direct, zero-cost mapping between C++'s `std::string_view` and Carbon's `Core.Str` for C++ interoperability. The goal is to make C++ APIs that use `std::string_view` feel native and seamless when used from Carbon. This mapping relies on the two types having an identical memory representation, a condition that we will work to ensure across all supported platforms.
This commit is contained in:
Boaz Brickner
@@ -0,0 +1,187 @@
|
||||
# C++ Interop: Mapping `std::string_view` to `Core.Str`
|
||||
|
||||
<!--
|
||||
Part of the Carbon Language project, under the Apache License v2.0 with LLVM
|
||||
Exceptions. See /LICENSE for license information.
|
||||
SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
||||
-->
|
||||
|
||||
[Pull request](https://github.com/carbon-language/carbon-lang/pull/6177)
|
||||
|
||||
<!-- toc -->
|
||||
|
||||
## Table of contents
|
||||
|
||||
- [Abstract](#abstract)
|
||||
- [Problem](#problem)
|
||||
- [Background](#background)
|
||||
- [Proposal](#proposal)
|
||||
- [Details](#details)
|
||||
- [Rationale](#rationale)
|
||||
- [Alternatives considered](#alternatives-considered)
|
||||
- [1. Provide a Wrapper Type](#1-provide-a-wrapper-type)
|
||||
- [2. Do Nothing](#2-do-nothing)
|
||||
|
||||
<!-- tocstop -->
|
||||
|
||||
## Abstract
|
||||
|
||||
This proposal defines a direct, zero-cost mapping between C++'s
|
||||
`std::string_view` and Carbon's `Core.Str` for C++ interoperability. The goal is
|
||||
to make C++ APIs that use `std::string_view` feel native and seamless when used
|
||||
from Carbon. This mapping relies on the two types having an identical memory
|
||||
representation, a condition that we will work to ensure across all supported
|
||||
platforms.
|
||||
|
||||
## Problem
|
||||
|
||||
Seamless interoperability with C++ is a core goal for Carbon. `std::string_view`
|
||||
has become a ubiquitous, fundamental type in modern C++ for passing non-owning
|
||||
string data. Without a direct mapping, Carbon developers would be forced to work
|
||||
with ABI-incompatible wrapper types or manually unpack `std::string_view`
|
||||
instances into pointers and sizes.
|
||||
|
||||
This creates significant friction:
|
||||
|
||||
1. **Ergonomics:** C++ APIs would not feel idiomatic. Developers would need to
|
||||
perform constant, boilerplate conversions.
|
||||
2. **Performance:** Any wrapper-based solution would break the zero-cost
|
||||
abstraction principle, potentially introducing overhead at the boundary.
|
||||
3. **Adoption:** The lack of seamless integration for such a basic type would
|
||||
be a significant barrier to migrating or integrating C++ codebases.
|
||||
|
||||
To provide a truly smooth migration path and interoperability story, Carbon must
|
||||
treat `std::string_view` as a first-class citizen, ideally as the same type as
|
||||
its native string view.
|
||||
|
||||
## Background
|
||||
|
||||
Carbon's `Core.Str` is, per
|
||||
[#5969](https://github.com/carbon-language/carbon-lang/issues/5969), the
|
||||
language's fundamental non-owning view of a sequence of bytes. It is
|
||||
[currently implemented as a pair of a pointer to the data and a 64-bit integer representing the size in bytes](https://github.com/carbon-language/carbon-lang/blob/7c13bddc92be8ceac758189df76ebbb048e1a9d5/core/prelude/types/string.carbon#L19-L22).
|
||||
The assumed memory layout is the pointer followed by the size.
|
||||
|
||||
C++'s `std::string_view` serves the same purpose. However, its memory layout is
|
||||
not standardized and varies between standard library implementations. This is
|
||||
critical for ABI compatibility.
|
||||
|
||||
The layouts for major C++ standard library implementations are as follows:
|
||||
|
||||
| Standard Library | Platform/Compiler | Member Order | Size Type (`size_t`) | Notes | Source |
|
||||
| ---------------- | -------------------- | -------------------- | -------------------- | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **libc++** | Clang (macOS, etc.) | `__data_`, `__size_` | 64-bit (on 64-bit) | Pointer first, then size. | [`string_view`](https://github.com/llvm/llvm-project/blob/fd5bc6033e521b946f04cb9c473d9cca3da2da9b/libcxx/include/string_view#L711-L712) |
|
||||
| **MSVC STL** | Microsoft Visual C++ | `_Mydata`, `_Mysize` | 64-bit (on 64-bit) | Pointer first, then size. | [`__msvc_string_view.hpp`](https://github.com/microsoft/STL/blob/ba64eaaa8592c700949f3c09a0d8570b932828f5/stl/inc/__msvc_string_view.hpp#L1924-L1925) |
|
||||
| **libstdc++** | GCC (Linux, etc.) | `_M_len`, `_M_str` | 64-bit (on 64-bit) | **Size first, then pointer.** | [`string_view`](https://github.com/gcc-mirror/gcc/blob/6b999bf40090f356c5bb5ff8a82e7e0dc4c4ae05/libstdc%2B%2B-v3/include/std/string_view#L590-L591) |
|
||||
|
||||
As the table shows, there is a key difference in member ordering, with
|
||||
`libstdc++` being the outlier compared to the assumed layout of `Core.Str`.
|
||||
|
||||
## Proposal
|
||||
|
||||
We propose to map C++ `std::string_view` directly to Carbon's `Core.Str` when
|
||||
importing C++ headers. This means the Carbon compiler will treat
|
||||
`std::string_view` as a type alias for `Core.Str` at the ABI level.
|
||||
|
||||
To achieve this, the following conditions must be met:
|
||||
|
||||
1. **Identical Representation:** The memory layout (sequence of fields, size,
|
||||
and alignment) of `std::string_view` and `Core.Str` must be identical for
|
||||
the target platform and C++ standard library.
|
||||
2. **Platform-Wide Compatibility:** The ultimate goal is for this mapping to
|
||||
work seamlessly across all Carbon-supported architectures.
|
||||
|
||||
Initially, this direct mapping will be enabled only for targets where the
|
||||
representation is known to match. For other platforms, we will pursue one of two
|
||||
strategies:
|
||||
|
||||
- Work with standard library vendors (for example, `libstdc++`) to align on a
|
||||
consistent representation for `std::string_view` across architectures,
|
||||
falling back to providing a patched version of these libraries if necessary.
|
||||
- Adapt the memory layout of Carbon's `Core.Str` on a per-platform basis to
|
||||
match the target's native `std::string_view` ABI.
|
||||
|
||||
This ensures that while the initial implementation may be constrained, the
|
||||
long-term design is for universal, zero-cost compatibility.
|
||||
|
||||
## Details
|
||||
|
||||
The initial implementation will assume `Core.Str` has a `(pointer, size)`
|
||||
layout. This means the direct mapping will work out-of-the-box on platforms
|
||||
using `libc++` (Clang) and MSVC STL.
|
||||
|
||||
For platforms using `libstdc++`, the current `(size, pointer)` layout is
|
||||
incompatible. The direct mapping will be disabled on these platforms by default
|
||||
until compatibility is achieved. Our strategy is to first align `Core.Str`'s
|
||||
layout with the dominant `(pointer, size)` convention used by Clang and MSVC. We
|
||||
will then engage with the `libstdc++` community to explore standardizing this
|
||||
layout for better cross-compiler compatibility.
|
||||
|
||||
Furthermore, `Core.Str` is defined with a 64-bit size field. C++
|
||||
`std::string_view` uses `size_t`, which is 32-bit on 32-bit targets. Therefore,
|
||||
this direct mapping will initially be restricted to 64-bit targets, which are
|
||||
Carbon's primary focus.
|
||||
|
||||
It is essential to recognize that both `Core.Str` and `std::string_view` are
|
||||
fundamentally views over bytes, not Unicode characters. This proposal maintains
|
||||
that semantic alignment. If Carbon requires a string type that understands
|
||||
character boundaries, it should be a separate, distinct type in the standard
|
||||
library and not interfere with this fundamental C++ interoperability mechanism.
|
||||
|
||||
## Rationale
|
||||
|
||||
This proposal directly supports the following Carbon goals:
|
||||
|
||||
- **Interoperability with and migration from existing C++ code:**
|
||||
`std::string_view` is one of the most common types in modern C++ interface
|
||||
design. A seamless mapping is not a luxury but a requirement for effective
|
||||
interoperability.
|
||||
- **Performance-critical software:** By ensuring a direct, zero-cost mapping,
|
||||
we avoid any performance penalties at the C++/Carbon boundary for string
|
||||
data. This is critical for systems programming where such overhead is
|
||||
unacceptable.
|
||||
- **Code that is easy to read, understand, and write:** A direct mapping
|
||||
allows developers to think of `std::string_view` and `Core.Str` as the same
|
||||
concept, reducing cognitive load and eliminating the need for manual
|
||||
conversions.
|
||||
- **Naming of `Core.Str`:** The choice of `Str` over `String` for the
|
||||
non-owning view type is intentional. It avoids confusion with owning types
|
||||
like C++'s `std::string`. `Str` is introduced as a new term of art for
|
||||
Carbon, providing a concise and readable name for this fundamental type. The
|
||||
shorter name is preferred for its clarity and reduced verbosity, especially
|
||||
for a type that will be used frequently. This is based on the decision in
|
||||
leads question
|
||||
[#5969](https://github.com/carbon-language/carbon-lang/issues/5969).
|
||||
|
||||
By defining a clear path toward universal ABI compatibility for this type, we
|
||||
are building a solid foundation for deep and performant integration with the
|
||||
existing C++ ecosystem.
|
||||
|
||||
## Alternatives considered
|
||||
|
||||
### 1. Provide a Wrapper Type
|
||||
|
||||
We could choose to always import `std::string_view` as an opaque Carbon struct,
|
||||
for example, `Core.Cpp.string_view`.
|
||||
|
||||
- **Advantages:** This would be ABI-safe on all platforms immediately.
|
||||
- **Disadvantages:** This approach is not seamless. It would require explicit
|
||||
conversions between `Core.Str` and `Core.Cpp.string_view`, adding
|
||||
boilerplate and potential performance overhead. It violates the goal of
|
||||
making C++ APIs feel native to Carbon.
|
||||
|
||||
### 2. Do Nothing
|
||||
|
||||
We could leave it to the developer to manually handle `std::string_view` by
|
||||
accepting it as an opaque type and using C++ helper functions to extract the
|
||||
pointer and size.
|
||||
|
||||
- **Advantages:** Simplest to implement in the compiler.
|
||||
- **Disadvantages:** This provides a terrible developer experience and runs
|
||||
directly counter to Carbon's core goal of excellent C++ interoperability. It
|
||||
would make using a vast number of modern C++ libraries prohibitively
|
||||
difficult.
|
||||
|
||||
The proposed approach of a direct mapping is superior as it prioritizes the
|
||||
long-term goals of performance and ergonomics, even if it requires a phased
|
||||
implementation to achieve full platform support.
|
||||
Reference in New Issue
Block a user