:question: Why C++17 has been chosen for the implementation? (and not C++20?)

[krzysztof-jusiak]

[chandlerc]

At the time, C++20 was still very incomplete in the released compiler we were using.

If there is a good motivation, we can consider switching.

[krzysztof-jusiak]

I see, IMHO, concepts, coroutines (modules) would defo have the ability to simplify/improve the implementation as there are already workarounds for some C++20 features in the code.I personally think it's a great selling point to bring more devs into the project as well. Working on open-sourced C++ successor compiler with the newest C++20 standard sounds like a win-win combination and a great selling point for devs looking to contribute. Whether that is a good enough reason to switch, I'd hope so but I'm not sure how much effort that would be? But if there is any desire to do so, I'm more than happy to volunture to do the work and enable C++20?

[marbub]

At the time, C++20 was still very incomplete in the released compiler we were using.

If there is a good motivation, we can consider switching.

I think to get taken seriously for C++ interoperability C++20 support is important. Sadly Clang makes not much progress for C++ 20. I know C++ developer who already think Clang is dead and this is an example that you should be careful to trust a project which is driven by a big company.

[rconde01]

We can talk about C++20, but i think the real point is that Carbon is choosing to freeze compatibility with C++ to a max version? What about 23/26/etc.? Basically, after you start using Carbon, don't use any new C++ features. The code you have is stuck, and for new code you should be using Carbon. If this is the case, then I guess you should freeze to what will be available when Carbon is a true alternative (29?).

It's certainly a jagged edge to the story. It would be much nicer to say that compatibility with newer versions of C++ will be added as they are released.

[KateGregory]

No-one has said "freeze". Right now, we're working to interop with C++17. Once that's working, I am sure plenty of people will want to interop to various C++20 features. It might take a while, but since C++ interop is a major goal, it will happen. We certainly haven't said we won't add that interop compatibility and I think concluding that we won't is the wrong guess.

As for saying "compatibility with newer versions of C++ will be added as they are released", sure, but trying to add that somewhere is likely to stir up a lot of bikeshedding about what "released" means or how long after that we are promising to have the compatibility. We don't have compatibility with 17 yet. Let's work on that.

[rconde01]

I, like I'm sure many others, are just trying to get my head wrapped around this - so I apologize if I'm making bad assumptions. From @chandlerc comment "If there is a good motivation, we can consider switching.", it seemed like "we have chosen C++17 at the max version Carbon will be compatible with...if you can prove a good use case, we might consider switching that to C++20". That seem to be implied by the need for the motivation, since otherwise the motivation simply is being compatible with all published C++ standards (at least eventually). But I guess I interpreted it wrong.

[chandlerc]

I think there is a lot of confusion here.

The issue, in the title, is about the implementation of Carbon's tools.

Our interoperability and migration goals are completely separate from what version we use when building the Carbon Explorer itself, or to write the toolchain. Those will obviously have to track whatever is being used in the C++ codebases that folks need Carbon code to interoperate with and migrate from.

But our implementation language version is completely independent of that. My comment at the top is purely and exclusively about implementation.

[aaronmondal]

I think it would be really nice to use C++20 as the current implementation standard for Carbon itself (not talking about interop, but the Carbon repo itself). IMO it just "makes sense" to use the most modern standard available for a new project.

Besides, migration from C++17 to C++20 won't be too complicated for a repo of the size of the current Carbon repo. I think that everyone who is able to build carbon will have a C++20 capable compiler/stdlib.

Also, just because it is "officially" C++20 doesn't mean that all new features HAVE to be used immediately (I'm not even sure that bazel supports modules right now, but constraints and <ranges> may be quite useful).

[aaronmondal]

On second thought, scratch that. This would only be viable if everyone used the same compiler. Different users will use different host toolchains. The implementation of C++20 features is currently too different between e.g GCC and Clang. The only solution I can think of would be to use a hermetic toolchain, but that is unrealistic considering that most users won't have a dedicated compile server 😅.

So I'd say that it actually doesn't make sense to switch right now.

[aaronmondal]

For reference, the current build has around 600 targets. While this repo technically could use the Bazel Clang targets to distribute a hermetic toolchain, the number of targets would spike to 2000-3000. I speculate that these targets would increase compile time by around 10x to 20x. This is not viable just to test an explorer. It seems also rather out of scope (and it's actually not that easy to implement). It would also make the repo potentially heavily dependent on specific clang commits. All in all this would currently be a bad idea for this repo.

[libbooze]

Our interoperability and migration goals are completely separate from what version we use when building the Carbon Explorer itself, or to write the toolchain. Those will obviously have to track whatever is being used in the C++ codebases that folks need Carbon code to interoperate with and migrate from.

I am still confused. This is what current docs say:

Carbon's language goal for interoperability will focus on C++17 compatibility. The language design must be mindful of the prioritization; trade-offs harming other goals may still be made so long as they offer greater benefits for interoperability and Carbon as a whole.

To be fair after first sentence I am kind of lost what the meaning of paragraph is. ¯_(ツ)_/¯

I dont want to make drama out of nothing, but a lot of enthusiasts that may be needed for outside(of Google) adoption of Carbon might not be interested since they months ago changed their C++ version to 23...

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please comment or remove the inactive label. The long term label can also be added for issues which are expected to take time. This issue is labeled inactive because the last activity was over 90 days ago.

[chandlerc]

FWIW, https://github.com/carbon-language/carbon-lang/pull/2365 aims to remove the confusion here somewhat.

[libbooze]

FWIW, #2365 aims to remove the confusion here somewhat.

For me this closes the issue, would be nice if we would have more details, e.g. what about modules or coroutines, but I presume you are not hiding anything(it is just not decided/done).