Better to be explicit about which design principles are relevant here. For example, it could be about adding overhead to compiles that don't need it which falls under "Fast and scalable development".

Thanks!
I think the overhead depends on the implementation and we could avoid any significant impact.
I was actually thinking about "principle of least surprise". Clarified.

I wonder if there has been much discussion about this option?

These seem awfully like what we would want in a "prelude" like construct for C++. We already have a prelude that brings in names in Core, and the Cpp package name is going to be similarly special (or more special) to Core due to it enabling the C++ importing. For example, it isn't reasonable to define a Carbon file with the package name Cpp.

So maybe that argues that this should be part of Carbon's prelude, and that prelude should introduce names both in Core and Cpp?

(If this is controversial or we want a longer discussion, maybe this should be factored into a leads issue.)

I think I'd be happy with this if we make Cpp a keyword (see https://docs.carbon-lang.dev/docs/project/principles/namespace_cleanliness.html#exceptions). Though in another leads issue we did just suggest adding names Core.Cpp.Long32 etc, which would presumably add another special case if Cpp is a keyword.

Notably we made Cpp a keyword in the toolchain already because it simplifies the implementation.

FTR, the suggestion to add Core.Cpp.Long32 is here.

I think Cpp is currently only special when used as a top namespace, and it can be used by users elsewhere.
I guess if it's an official keyword, we should not allow using it elsewhere.

I think introducing Cpp as part of Carbon language by default means we don't just support great interop with C++, we incorporate C++ names as part of Carbon.
Future users of pure Carbon might find having Cpp.long in pure Carbon a bit surprising and legacy of C++.

I agree Core is somewhat similar, but Core is probably necessary for almost any Carbon based project, and Cpp is not necessary for future pure Carbon projects.

I think we could make a decision between the proposed solution here and alternative 2. If we decided on alternative 2, I'll be happy to create a new proposal for that and close this one. I can also create a leads question, but I feel like this would just split the discussion unnecessarily.

Chatted a bit with @zygoloid and I think we're both increasingly comfortable with this alternative, and making Cpp a keyword and refer to the special Cpp package.

That will force us to use a different namespace inside of Core for types like Long32, but that's probably good -- these aren't ways of naming the C++ name, but the Carbon type that is used for compatibility with a specific C++ name. Basic suggestion for #6275 names is Core.CppCompat.*.

Thanks!
To clarify, we want to not support import Cpp; and instead, when there's no import Cpp ... (library or inline), and the Cpp keyword is used (e.g. Cpp.long or even Cpp.MyType), we will trigger AST creation so we can query it.
In other words, Cpp and Cpp.<builtin_type> are always found, regardless of whether we explicitly imported Cpp.
Correct?