How can this work?

[L4stR1t3s]

I really don't see how you can promise C++ interoperability without adhering to the same basic principles.

Let me explain with an example. I will write pseudo carbon code because I really haven't studied the preliminary syntax proposal in-depth, so please don't correct me.

• add.h (C++ header file)

// Take 2 values and return their sum
template <typename T>
T add(T left, T right)
{
	return left + right;
}

• add.carbon (Carbon source file)

include <add.h> // include the C++ header file

fn main()
{
	var a : uint8 = 200;
	var b = add(a, a); // overflow
}

Since add() is a template function, it can't be precompiled, so it will have to be evaluated when compiling add.carbon. According to the documentation, Carbon does not allow uint8 overflows (https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/primitive_types.md#overview). But C++ does, so what will happen in this case?

What happens if we turn it around? Because bi-directional interoperability is promised as well. What if the template function is written in Carbon and we call it from C++? What happens then?

You can't possibly suggest doing something different? You can't claim C++ interoperability if a C++ function does something different depending on whether you call it from C++ or Carbon, and vice versa.

[OlaFosheimGrostad]

I don't know what they intend to do, but the natural thing to do is to choose an internal compiler representation (IR) where overflow, no-overflow, wrapping, saturation etc is encoded in the operators. The compiler could translate 'a+b' originating from C++ as a wrapping-add operator in the IR whereas 'a' and 'b' are type-tagged bitvectors.