C++ Interop: API importing and semantics

[bricknerb]

This proposal defines the concrete technical mechanisms for C++
interoperability. It specifies the precise syntax and semantics for importing
C++ APIs. This includes the import Cpp library "..." and implicitly importing
C++ built-in entities, and the establishment of the Cpp package as the
dedicated namespace for all imported entities.

This PR also includes high level language C++ Interop design and the basics of importing C++ APIs and function calling.
Leaving plenty of TODOs to make it easier to fill in more details in followups.

Part of #4666.

[jonmeow]

I think there's an important distinction of implementation versus design... Where you talk about a specific implementation requirement using Clang, I think that's a toolchain design detail. That'd suggest to me that the details are more appropriate for toolchain/docs (implementation) than docs/design (language design).

That is, for our implementation, we have chosen to use Clang and we're making implementation trade-offs based on that. However, if someone chose to build their own Carbon compiler, they should have freedom to choose a C++ compiler that suited them so long as it fit the higher-level language needs.

Also for language design, I think we typically want proposals first, then language design changes (or, put the language design change in with the proposal). But I'm just going to swap myself out for review with zygoloid since that's more of a leads choice, and he's also familiar with what's being done here.

[jonmeow]

Just highlighting a few things from a read-through, but trying not to get into many details because of the mix of design and implementation here.

[bricknerb]

I think there's an important distinction of implementation versus design... Where you talk about a specific implementation requirement using Clang, I think that's a toolchain design detail. That'd suggest to me that the details are more appropriate for toolchain/docs (implementation) than docs/design (language design).

That is, for our implementation, we have chosen to use Clang and we're making implementation trade-offs based on that. However, if someone chose to build their own Carbon compiler, they should have freedom to choose a C++ compiler that suited them so long as it fit the higher-level language needs.

Also for language design, I think we typically want proposals first, then language design changes (or, put the language design change in with the proposal). But I'm just going to swap myself out for review with zygoloid since that's more of a leads choice, and he's also familiar with what's being done here.

Thanks Jon!
I've edited this to focus on language design, removing implementation specific parts including the entire TODO section for thunks.

[bricknerb]

I think there's an important distinction of implementation versus design... Where you talk about a specific implementation requirement using Clang, I think that's a toolchain design detail. That'd suggest to me that the details are more appropriate for toolchain/docs (implementation) than docs/design (language design).
That is, for our implementation, we have chosen to use Clang and we're making implementation trade-offs based on that. However, if someone chose to build their own Carbon compiler, they should have freedom to choose a C++ compiler that suited them so long as it fit the higher-level language needs.
Also for language design, I think we typically want proposals first, then language design changes (or, put the language design change in with the proposal). But I'm just going to swap myself out for review with zygoloid since that's more of a leads choice, and he's also familiar with what's being done here.

Thanks Jon! I've edited this to focus on language design, removing implementation specific parts including the entire TODO section for thunks.

Waiting for @zygoloid review.

[zygoloid]

This seems reasonable, but I think there are details here that haven't been through the proposal process, so it'd make sense to add a little pro forma /proposals/p6358.md here and treat this as a proposal so we can give it the weight of being an approved design change.

[bricknerb]

This seems reasonable, but I think there are details here that haven't been through the proposal process, so it'd make sense to add a little pro forma /proposals/p6358.md here and treat this as a proposal so we can give it the weight of being an approved design change.

I've created a proposal, which assumes the proposal #6254 is accepted.

[bricknerb]

This seems reasonable, but I think there are details here that haven't been through the proposal process, so it'd make sense to add a little pro forma /proposals/p6358.md here and treat this as a proposal so we can give it the weight of being an approved design change.

I've created a proposal, which assumes the proposal #6254 is accepted.

I've removed the dependency on #6254.
@zygoloid, PTAL.

[github-actions]

We triage inactive PRs and issues in order to make it easier to find active work. If this PR should remain active, please comment or remove the inactive label.

This PR is labeled inactive because the last activity was over 90 days ago. This PR will be closed and archived after 14 additional days without activity.

[zygoloid]

LGTM, with a couple of minor edits.

[chandlerc]

LG to me as well with the suggestions from @zygoloid

Let us know if we should merge those and land this or you want to!

[bricknerb]

Thanks!
Committed the suggestions.

[CarbonInfraBot]

[diff] _{reported by reviewdog 🐶}

Suggested change

	- [Code that is easy to read, understand, and write](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write)
	- **Explicitness and Clarity:** The `import Cpp library "..."` directives

[zygoloid]

Thank you!