C++ interoperability goals

[jonmeow]

Related threads:

• From austern, Initial draft of C++ Interoperability principles doc #62
• From me, Carbon <-> C/C++ interoperability #80
  • Doc
  • Ideas topic
  • RFC topic
• From chandlerc, Interop implementation strategies

For this PR:

• RFC topic
• Decision topic
• Decision announcement
• Decision PR

[kulakowski]

I might mention common language extensions here as well. They seem like something that could go through a case-by-case cost-benefit analysis like you suggest for CRTP.

Attributes seem like a good example.

I imagine that Carbon will have some way of expressing that a function doesn't return, or the type of a function that does not return. Clang knows about several such ways to express this in C and C++. And being able to pass a Carbon no-return function to a C++ function with a _Noreturn or [[noreturn]] parameter could be worthwhile. Similarly, non-null C++ attributes may be worth the effort.

Whereas attributes for Renderscript or Objective-C garbage collection may not be, and not be something Carbon provides any support for, let alone interoperability.

Interactions with the linker (specifying sections and so on) and inline assembly may fall in between. Carbon may need to provide functionality here, but maybe not interoperability with C++.

My point isn't so much the specific examples (though they are of general interest to the kind of programming I'm representing), but more that I'd suggest that this section is not complete, and not intended to be complete, and suggest that you leave room for evaluating particular extensions in the future.

[jonmeow]

I think that "most idiomatic usage of advanced C++ features" could be considered to cover this. I've added attributes explicitly there. Enumerating specific attributes is definitely too detailed for a "goals" doc.

[kulakowski]

This may be overly pedantic or covered in some other context I missed; sorry if so.

Sometimes this document says C/C++; sometimes it says C++.

In particular, right here it says "C++ migration". I wanted to know if this means really only migration from C++17, or if migration from C is something you are planning.

[jonmeow]

Sometimes this document says C/C++; sometimes it says C++.

That's a little deliberate in this doc: I've tried to be a little precise to avoid bikesheds of "oh, you plan C++ interop, but are ignoring C". I try to talk about C++ without C when talking about C++-specific features, like templates.

In particular, right here it says "C++ migration".

Please note, this is the phrasing of the language goal, not specific to this proposal.

I wanted to know if this means really only migration from C++17, or if migration from C is something you are planning.

Rephrased the first sentence to specify C++17.

[fowles]

s/will be/may be/

[jonmeow]

I prefer stronger phrasing, and I'm wondering if you're misunderstanding why "will" is appropriate -- I've elaborated a little to try to improve this point without softening it.

[fowles]

I think it may for some parts of safety and may not for others, so the stronger phrasing feels misleading

[jonmeow]

To make sure we're discussing the same text, the phrasing now is:
C/C++ code will not benefit from the same set of safety
mechanisms that Carbon offers, so Carbon code calling into C/C++ will accept
higher safety risks.

Are you saying that you feel this is still misleading? I think "same set" should address your concern regarding "some parts", shouldn't it?

[fowles]

I think we should state that the Carbon memory model for concurrency will also be compatible with C++ (possibly excepting memory_order_consume). And that a release in Carbon will establish a happens before relationship with an acquire in C++ and vice versa

[jonmeow]

Does this need to be part of the goals? It's important, yes, but is this detail really something for the high-level goals, versus a design about the memory model?

[fowles]

you are enumerating a bunch of "unsurprising mappings", it seems to make sense that this would be a good place to call out both the important of memory model and the fact that it will be unsurprising.

[chandlerc]

FWIW, I think having a goal around the fundamentals of the memory model makes a lot of sense. It is a question that has come up in multiple introductions to Carbon I've done so far...

[jonmeow]

I've added a "Compatibility with the C/C++ memory model" goal under "mixing toolchains", because it feels like a better fit there.

[fowles]

Nice addition there. Flows well

[jonmeow]

Thanks!

[fowles]

I would expect that a wrapper type + specialization would be sufficient to get nearly zero overhead access to std::vector<T> as an idiomatic carbon type. If we cannot provide this for unordered_map, string, and vector I would be quite worried about being able to incrementally migrate to idiomatic carbon.

[josh11b]

+1, we should aim to make generics efficient (from a runtime perspective, with some potential compile-time cost) for this use case.

[jonmeow]

Rephrased to avoid a performance argument. I'm not convinced that you can guarantee zero-overhead in every possible case with generics wrapping C++ types vs native idiomatic Carbon, but I don't think it's important here.

To be clear though, "nearly zero" and "zero" are important to differentiate if we're positioning Carbon as a performance-first language. If it's not zero, then we should anticipate that somebody will ask for a better option.

[fowles]

by "nearly zero" I think of the level of overhead that unique_ptr introduces. Not zero, but close enough to it that most everyone is satisfied most of the time.

[jonmeow]

Acknowledged, with my noted concern -- actually captured under "Performance-critical software" already. However, I don't think that affects this section as written.

[josh11b]

Not a sentence.

[jonmeow]

"A few examples are"

[josh11b]

+1, we should aim to make generics efficient (from a runtime perspective, with some potential compile-time cost) for this use case.

[josh11b]

Carbon templates can
be handled by adding C++ compiler code paths that use portions of the Carbon AST
generated by the Carbon template code.

This sentence is pretty central to understanding what your saying, but I didn't succeed in gathering what it was saying. Are you talking about C++ templates with Carbon types as parameters, or maybe Carbon templates with C++ types? These aren't what I think of if you say "Carbon templates". I don't know what "C++ compiler code paths" are -- "paths" reminds me of files, but I don't think that is what you mean.

[jonmeow]

Rephrased a little:
exposing the Carbon compiler's AST to the C++ compiler directly,
as a compiler extension

[josh11b]

You might point out that the operators will be different between Carbon and C++. For example, C++ uses << both for streamed output and binary shift left

[jonmeow]

I already talk a bit more about mixing toolchains than I'd like -- the section is pretty long. My sense is that it's better to avoid talking about operator<<, because of the amount of discussion that doing so would require, and it's not clear to me that it would add much:

• There's a design decision to be made about whether operator<< should really be that different.
• I'd expect any decision to address the C++ incompatibility, given the prevalence of use.
• There should still be some interoperable method for using C++'s operator<<, and likely even overloading it from Carbon, in order to support calling standard C++ code from Carbon.
• In context here, a template could rely on using whatever interoperable method is chosen.

Explaining all of this seems pretty expensive, and also possibly bleeds operator<< design choices into this "goals" proposal. I think it's better to stay at a high level.

[jonmeow]

Responding to zygoloid

[jonmeow]

Fine fine, replaced C/C++ with C. Added a specific C goal.

I disagree that C should not be mentioned here -- there are still many maintained systems that rely on C APIs, and I think that part of writing a successor to C++ is guaranteeing we can still interact with C APIs.

[jonmeow]

Added:
Any C++ interoperability code that works when mixing toolchains must work when
using the native Carbon toolchain. The mixed toolchain support must not have
semantic divergence. The converse is not true, and the native Carbon toolchain
may have additional language support and optimizations.

[jonmeow]

I think I was trying to say this, but rephrased this non-goal.

[jonmeow]

The latter, rephrased

[sidney13]

Accepted on 2020-11-24.

[chandlerc]

Explicitly leaving an LGTM on my part.

[jonmeow]

Related threads:

• From austern, Initial draft of C++ Interoperability principles doc #62
• From me, Carbon <-> C/C++ interoperability #80
  • Doc
  • Ideas topic
  • RFC topic
• From chandlerc, Interop implementation strategies
• Decision announcement