C++ Interop: Reserved identifiers

[JamesJCode]

This proposal reserves a space of identifiers to enable smooth and error-free C++ interop, and to provide a reserved namespace for internal Carbon implementation specifics.

[josh11b]

@carbon-language/carbon-leads A little bit of guidance from leads here would make the path forward clear which would make forward progress easier. In particular this PR is about the question: how much should we make reserved in Carbon since they are reserved in C++ and so using it in Carbon will make it harder to access from C++?

The two main categories of concern are:

• C++ keywords, which change, but not quickly (discussed in this thread).
• Identifiers with specific combinations of underscores and possibly capital letters (discussed in this thread)

Presumably we will either say these are all reserved in Carbon or there is some way to say "export this Carbon thing as something else in C++." Which one would you prefer? If we have a way to export things to C++ under a different name, do we want to reserve any of these in Carbon?

[chandlerc]

The two main categories of concern are:

• C++ keywords, which change, but not quickly (discussed in this thread).
• Identifiers with specific combinations of underscores and possibly capital letters (discussed in this thread)

Presumably we will either say these are all reserved in Carbon or there is some way to say "export this Carbon thing as something else in C++." Which one would you prefer?

I think we will really want a very nice, ergonomic way to export a C++-only alias. There are lots of reasons I can imagine here beyond the collisions you mention (dealing with changes to naming conventions, namespace/package name structures, etc). But they'll work just as well to address the collisions you mention.

I also think there is a third option that I would like to include: add a compiler extension to achieve a "raw identifier" in C++. I think we should try to get that into Clang at least, and use it when we can. There are also other users that would benefit from this. It already exists in MSVC's C++/CLI mode (__identifier(...)) and has been requested several times before. We can at least contemplate ensuring this is available in our primary interop host toolchain. The use case here is preserving API aliases for existing code in old language standards.

Personally, I think we should try to have both of these things to give ourselves lots of flexibility.

If we have a way to export things to C++ under a different name, do we want to reserve any of these in Carbon?

After thinking about the above, my guess (but this is just a very weak guess on my part) is that we shouldn't try to use reserved identifier space to avoid these collisions.

But I think there is some utility in having a strong convention about how to write grammatically valid identifiers that explicitly don't collide with user code. And similarly, I think its useful to give implementations a space they can use if actually rewriting source code is desirable for some reason (even though I don't think this is how we should realistically implement things in practice).

So I would still suggest reserving some space, but more for our own purposes.

I would also suggest having the Carbon reserved names be visually similar and within the reserved space for C/C++. My personal suggestion would just be the extremely simple rule of names starting with __. This is much simpler than C++'s rules, but conventional and familiar. It gives us at least some space if useful.

My two cents.

[JamesJCode]

FWIW I've basically come to the same conclusion (less the adding raw identifiers to the C++ compiler idea). For exported names, this could look like having something following the attribute syntax such as:

@Cpp.ExportAs("CppFunction")
fn CarbonFunction(){...}

@Cpp.ExportAs("CppClass")
class MyClass {
   @Cpp.ExportAs("CppMember")
   var carbon_member: i32;
}

[github-actions[bot]]

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.

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this PR should remain active or becomes active again, please reopen it. This PR was closed and archived because there has been no new activity in the 14 days since the inactive label was added.