Carbon/C++ Interop: Primitive Types proposal #5448

ivanaivanovska · 2025-05-08T11:01:20Z

A proposal for Primitive Types mapping between Carbon and C++.

Part of #5263

jonmeow

Generally looks good to me, I think the conversions align. Looking through this did make me realize I'd missed the Core.Cpp naming -- sorry about that.

proposals/p5448.md

jonmeow · 2025-05-23T15:50:39Z

proposals/p5448.md

+-   Carbon `iN` types will map to C++ `intN_t` types (for example `i32` ->
+    `int32_t`).
+-   `long`, `long long` in C++ will map to new Carbon types (for example
+    `Core.Cpp.long/long_long`).


@zygoloid What was your intent for where long falls? I'd been assuming Cpp.long, and missed that the design was writing Core.Cpp.long until now. I think there are some behavioral trade-offs:

If it's in a non-prelude Core library, it's presumably implicitly imported when import Cpp is written, but not added to name lookup. I think this would require some work on import boundaries.

If it's in the prelude, then we're privileging a C++ type in a way that we might not want to echo for other programming languages (or even other C++ types).

If it's in a Cpp-packaged library implemented in Carbon code, then we might need some special-casing to allow package Cpp, but it could behave similar to export import for a user.

If it's treated similar to other C++ types, it could just be added every time import Cpp is processed. So it's still Cpp.long, and conversions to Carbon types work, but it's still a little special because that's not how most C++ types work.

Per discussion in the interop meeting and separate discussion with @chandlerc, I think our preference here is Cpp.long, Cpp.long_long, and so on. I don't think we've explicitly discussed keyword order, but I'm assuming it's:

Cpp.[unsigned_](long_long|long|int|short|double|float)

That is: signedness, then size keyword(s), then a type keyword only if there were no size keywords. (So unsigned_int not unsigned, long not long_int.)

Some mention of why we think it's OK to do this despite the risk of name collisions would be great to include in this proposal.

We should include in "Alternatives considered" at least three other options:

Allow all keyword permutations. Reason not to do this: it's unnecessary and complicated.

Only include the keywords, and provide some syntax for combining them (eg, Cpp.unsigned & Cpp.long or Cpp.unsigned(Cpp.long)). Reason to do this: avoids taking any identifiers from Cpp that are not C++ keywords. Reason not to do this: overly complicated.

Use Core.Cpp.blah instead of Cpp.blah. Reason to do this: avoid name collisions with C++ code. Reason not to do this: we don't think the name collisions are a problem in practice, and would prefer to keep C++-specific stuff in package Cpp.

Thanks. Done.

bricknerb · 2025-05-27T11:13:47Z

proposals/p5448.md

+    -   `f16`, `f32`, and `f64` - always available
+    -   `f80`, `f128`, or `f256` may be available, depending on the platform
+
+### C++ Fundamental Types


Perhaps let's improve consistency on how we write platform specific notes.
I suggest:

<Platform>: definition Other: definition

Also, I don't think we need to mention that LP32 is not Carbon supported several times, we can have it as a note at the beginning or at the end, and clarify that for now we're considering this platform as not supported.

If you say it in the beginning, you can also decide to just ignore it in the table, so it might be useful to have that information (perhaps you can move it to a different place).

bricknerb · 2025-05-27T11:18:27Z

proposals/p5448.md

+
+**Standard floating-point types**
+
+| Type          | Format                            | Width in bits    | Note                                                                        |


Add links to the specific formats.

bricknerb · 2025-05-27T11:22:33Z

proposals/p5448.md

+[LP64](/proposals/p5448.md#data-models)). Historic platforms like
+[LP32](/proposals/p5448.md#data-models) won't be supported.
+
+## Proposal


Can we say explicitly that if C++ considered two types to be different types, Carbon would treat them as different types as well?
I see you write it below, but you can put it above instead to clarify this guides the mapping.

bricknerb · 2025-05-27T11:26:23Z

proposals/p5448.md

+| `Core.Cpp.unsigned_long`      | `unsigned long`, [LP64](/proposals/p5448.md#data-models): `uint_fast64_t`, `uint_least64_t`, `uintmax_t`, `uintptr_t`, `size_t`                              |
+| `Core.Cpp.unsigned_long_long` | `unsigned long long`, [LLP64](/proposals/p5448.md#data-models): `uint_fast64_t`, `uint_least64_t`, `uintmax_t`                                               |
+| `Core.Cpp.long_double`        | `long double`                                                                                                                                                |
+| X (No mapping)                | `float32_t`, `float64_t`, `bfloat16_t`                                                                                                                       |


We should probably map them eventually, why not TBD?

zygoloid · 2025-06-10T22:53:40Z

proposals/p5448.md

+-   Carbon `iN` types will map to C++ `intN_t` types (for example `i32` ->
+    `int32_t`).
+-   `long`, `long long` in C++ will map to new Carbon types (for example
+    `Core.Cpp.long/long_long`).


Per discussion in the interop meeting and separate discussion with @chandlerc, I think our preference here is Cpp.long, Cpp.long_long, and so on. I don't think we've explicitly discussed keyword order, but I'm assuming it's:

Cpp.[unsigned_](long_long|long|int|short|double|float)

That is: signedness, then size keyword(s), then a type keyword only if there were no size keywords. (So unsigned_int not unsigned, long not long_int.)

Some mention of why we think it's OK to do this despite the risk of name collisions would be great to include in this proposal.

We should include in "Alternatives considered" at least three other options:

Allow all keyword permutations. Reason not to do this: it's unnecessary and complicated.

Only include the keywords, and provide some syntax for combining them (eg, Cpp.unsigned & Cpp.long or Cpp.unsigned(Cpp.long)). Reason to do this: avoids taking any identifiers from Cpp that are not C++ keywords. Reason not to do this: overly complicated.

Use Core.Cpp.blah instead of Cpp.blah. Reason to do this: avoid name collisions with C++ code. Reason not to do this: we don't think the name collisions are a problem in practice, and would prefer to keep C++-specific stuff in package Cpp.

zygoloid · 2025-06-10T22:55:18Z

proposals/p5448.md

+| `Core.Cpp.long`               | `long`, [LP64](/proposals/p5448.md#data-models): `int_fast64_t`, `int_least64_t`, `intmax_t`, `intptr_t`, `ptrdiff_t`                                        |
+| `Core.Cpp.long_long`          | `long long`, [LLP64](/proposals/p5448.md#data-models): `int_fast64_t`, `int_least64_t`, `intmax_t`                                                           |
+| `Core.Cpp.unsigned_long`      | `unsigned long`, [LP64](/proposals/p5448.md#data-models): `uint_fast64_t`, `uint_least64_t`, `uintmax_t`, `uintptr_t`, `size_t`                              |
+| `Core.Cpp.unsigned_long_long` | `unsigned long long`, [LLP64](/proposals/p5448.md#data-models): `uint_fast64_t`, `uint_least64_t`, `uintmax_t`                                               |
+| `Core.Cpp.long_double`        | `long double`                                                                                                                                                |


Do we add just these five [Core.]Cpp.something types, or all the C++ types, including the ones with an effectively fixed mapping? It'd be more consistent to add them all.

Added them all, PTAL.

zygoloid · 2025-06-10T23:02:10Z

proposals/p5448.md

+    -   `Core.Cpp.long`: either 32-bit or 64-bit, and use an appropriate int
+        type that is compatible with (but different) from `i32`/`i64`.
+    -   `Core.Cpp.long_long`: a platform dependent alias to `i64`.


It's not completely clear to me what model is being proposed here. I think the main options are:

Cpp.long and Cpp.long_long both map to Carbon types that are distinct from iN for any N, but are compatible with either i32 or i64 as appropriate.

If int64_t is long then Cpp.long is i64 and if int64_t is long long then Cpp.long_long is i64. Whichever types don't map to iN are distinct Carbon types that are compatible with iN instead.

int, long, and long long all map to one of i32 or i64. This means two different C++ types map to the same Carbon type.

Your alternatives considered says why we're not doing option 3. But I think we should also consider whether we want option 1 or option 2. I think the description in this proposal is saying we'd do option 1, but we'd at least previously been talking about doing option 2 instead. That seems to be a reasonable rule that can be described without explicitly treating long and long long as special cases:

intN_t in C++ is always the same type as iN in Carbon. And likewise for uintN_t / uN.

builtin type in C++ is always the same type as Cpp.builtin_type in Carbon for some specified set of builtin types.

As a consequence, builtin types in C++ that aren't the same as intN_t or uintN_t for any N end up being nameable in Carbon only as Cpp.builtin_type.

Thanks. I updated the proposal to reflect on these comments, PTAL.

zygoloid · 2025-06-10T23:06:34Z

proposals/p5448.md

+Carbon won't have aliases or distinct types for `int_fastN_t`, `int_leastN_t`,
+`intmax_t`, `intptr_t`, `ptrdiff_t`, `size_t`. This may be reconsidered in the
+future if need arises.


Might be worth pointing out that Cpp.size_t etc will exist if the C++ header declaring the typedef is imported, so we don't need any explicit support for these.

ivanaivanovska · 2025-06-18T09:59:29Z

I updated the Proposal, Details and Alternatives sections to reflect on the comments. Will go later through the comments on the Background section.

Initial setup for the Primitive Types proposal

53b8df5

github-actions bot added the proposal A proposal label May 8, 2025

ivanaivanovska added 8 commits May 8, 2025 11:33

Rename Primitive Types proposal

900301b

Fill in Proposal and Details sections

f4d1da8

Fill in Primitive Type Backgroud

9c5696f

Add more details to the Background

7e5279f

Add more details on the integer types (int_fastN_t, int_leastN_t etc.)

c5c3317

Add details on void and nullptr_t

9d98eed

Add Rationale and Alternatives

7431036

Minor refactoring

65d485a

ivanaivanovska marked this pull request as ready for review May 23, 2025 09:43

github-actions bot added the proposal rfc Proposal with request-for-comment sent out label May 23, 2025

github-actions bot requested a review from KateGregory May 23, 2025 09:43

jonmeow reviewed May 23, 2025

View reviewed changes

Address review comments

d1c051d

ivanaivanovska requested a review from jonmeow May 26, 2025 08:20

ivanaivanovska mentioned this pull request May 26, 2025

C++ interop: Add support for C++ Primitive Types #5263

Open

bricknerb self-requested a review May 27, 2025 11:00

bricknerb reviewed May 27, 2025

View reviewed changes

jonmeow requested a review from zygoloid May 27, 2025 16:09

ivanaivanovska mentioned this pull request Jun 5, 2025

Rename splits for intN_t tests #5615

Merged

zygoloid reviewed Jun 10, 2025

View reviewed changes

ivanaivanovska added 4 commits June 18, 2025 08:55

Apply review suggestions in Proposal/Details/Alternatives sections

64242d6

Change naming of new types

9680369

Add rejected alternative

b9fff8e

Update rejected alternative

d11b4ac

ivanaivanovska requested a review from zygoloid June 18, 2025 09:57


		Standard floating-point types

		\| Type \| Format \| Width in bits \| Note \|

Carbon/C++ Interop: Primitive Types proposal #5448

Are you sure you want to change the base?

Carbon/C++ Interop: Primitive Types proposal #5448

Uh oh!

Conversation

ivanaivanovska commented May 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jonmeow left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ivanaivanovska Jun 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ivanaivanovska commented Jun 18, 2025

Uh oh!

Uh oh!

ivanaivanovska commented May 8, 2025 •

edited

Loading

ivanaivanovska Jun 18, 2025 •

edited

Loading