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

[ivanaivanovska]

Use Carbon: C++ Interop - Primitive Types doc as a reference for the type mappings.

• Signed integer types

Carbon type	C++ type	Status	PRs
i8	signed char / int8_t	TODO
i16	short / int16_t	DONE	#5393
i32	int / int32_t	DONE	#5197; #5392
Core.Cpp.long	long	TODO
Core.Cpp.long_long	long long	TODO
i64	int64_t	TODO

• Unsigned integer types

Carbon type	C++ type	Status
u8	unsigned char / uint8_t	TODO
u16	unsigned short / uint16_t	TODO
u32	unsigned int / uint32_t	TODO
Core.Cpp.unsigned_long	unsigned long	TODO
Core.Cpp.unsigned_long_long	unsigned long long	TODO
u64	uint64_t	TODO

• Floating-point types

Carbon type	C++ type	Status
f32	float	TODO
f64	double	TODO
TBD	long double	TODO

[jonmeow]

Note, for now maybe just i8/u8 for char types. We don't have a byte type yet, and we may want a char type.

For long, I'll also suggest forcing i64/u64 for now. We don't have Windows testing yet, but we need a clearer decision about how to handle cross-platform. It's possible we'll actually want a platform-dependent type for long ("Alternative: Provide variable size types" in the doc), and instead encourage int64_t for platform-independent use.

[jonmeow]

For integer types, discussion with @chandlerc and @zygoloid seems to have leaned (for now, at least):

• i8 == int8_t, which should be the same as signed char
  • And so on for i16, int16_t/short, and i32/int32_t/int
• i64 == int64_t, which should be either long or long long, platform-dependent
• There will be some Carbon name for both long and long long, although that name isn't clear (e.g., Core.Cpp.long and Core.Cpp.long_long, Core.Cpp.unsigned_long_long as a possible choice).
  • One of these will be a platform-dependent alias to i64. The other will be either 32-bit or 64-bit, and use an appropriate int type that is equivalent (but different) from i32/i64.
• Corresponding for unsigned types

When transforming Carbon types to C++, always use this mapping. When transforming C++ types to Carbon, fit into these buckets as much as possible.

[zygoloid]

Had some further discussion with @chandlerc about this, largely reaffirming the approach that @jonmeow described previously. Some new observations:

• We should make sure that the platform-dependent type that is not an alias for iN is nonetheless compatible with the corresponding iN type, for example by defining the non-alias type as an extending adapter of the alias type. In particular, this would allow us to type-pun between them and for example cast from Core.Cpp.long_long* to i64* even when long_long is not an alias for i64.
• Once we reach the point of using C++ overload resolution for function calls in interop, we can consider allowing forming an implicit conversion sequence from (eg) one of the two 64-bit integer types to the other one.
• We will probably want to add a new type to Carbon at some point that is a machine-word-sized integer type (Core.Int(N) where N is pointer-width). We should check whether that type will always be the same type as ptrdiff_t / ssize_t under this model. We suspect it will, but there might be surprises lurking here.

[ivanaivanovska]

Thanks a lot for your input! @jonmeow @zygoloid
I started drafting a new design doc reflecting on these discussions in: Carbon: C++ Interop - Primitive Types. It’s still a WIP, but any early feedback is welcome. Thanks.

[rahiladmin]

Hey, I would like to work on this issue.

[ivanaivanovska]

The primitive types mapping proposal (#5448) is now open for review.

[ivanaivanovska]

Hey, I would like to work on this issue.

Thanks @rahiladmin for your interest in participating to this issue.

While the proposal (#5448) is still in review, the mapping of signed char/int8_t -> i8 can be implemented next and you could take that if you’re still interested. You could use as an example the implementation for short / int16_t -> i16 (PR #5393). If you work on this, please add myself and @bricknerb as reviewers and notify us of your work. Thanks!