3 ms·

>The two main backers (Apple and Google) seem to have backed out. Google has not "backed out". E.g. look at this topic's discussion thread. The current top c

by dxf 5y ago

>The two main backers (Apple and Google) seem to have backed out. Google has not "backed out". E.g. look at this topic's discussion thread. The current top comment is about [[clang::musttail]]; the implementor of that attribute works for Google. The current second top comment is about the Rust compilation wins from the switch to the New Pass Manager; the NPM was primarily implemented by (and turned on as the default pass manager upstream) by people who work for Google. Google is actually growing our investment in people contributing to core Clang/LLVM. Source: I am a manager for C++ toolchains (those that target production, Chrome, ChromeOS) at Google.

pjmlp 5y ago
From the point of view from C++20 support it definitely looks like that from the outside. Which you pretty much confirmed by giving examples completely unrelated to ISO. How is that migration to C++20 modules support going?
- dxf 5y ago
  If you are asking, "Is Google helping with any C++20 support upstream?" the answer is Yes. E.g. for standard concepts in libc++: std::derived_from (D74292) std::convertible_to (D77961) Arithmetic concepts (D88131) std::move_constructible (D96230) std::copy_constructible (D96232) std::invocable (D96235) std::regular_invocable (D96235) etc. Google is _big_ and C++ is used for many projects that build with disparate toolchains (even if they are all based on Clang/LLVM); each project can have different needs to adopt parts of C++20 sooner than the others, and different costs for doing so. Moving from Clang modules to C++ standard modules is an effort that, for some of our projects, lives at the nexus of "Are Standard Modules sufficiently done upstream to be able to replace our use of Clang modules?" and "What is the cost of doing that?" and "What is the benefit of making that switch?" For other projects, adopting standard modules is a more straightforward calculus.
  - pjmlp 5y ago
    Fair enough, thanks for the clarification.

by dxf 5y ago

pjmlp 5y ago

From the point of view from C++20 support it definitely looks like that from the outside. Which you pretty much confirmed by giving examples completely unrelated to ISO. How is that migration to C++20 modules support going?

dxf 5y ago
If you are asking, "Is Google helping with any C++20 support upstream?" the answer is Yes. E.g. for standard concepts in libc++: std::derived_from (D74292) std::convertible_to (D77961) Arithmetic concepts (D88131) std::move_constructible (D96230) std::copy_constructible (D96232) std::invocable (D96235) std::regular_invocable (D96235) etc. Google is _big_ and C++ is used for many projects that build with disparate toolchains (even if they are all based on Clang/LLVM); each project can have different needs to adopt parts of C++20 sooner than the others, and different costs for doing so. Moving from Clang modules to C++ standard modules is an effort that, for some of our projects, lives at the nexus of "Are Standard Modules sufficiently done upstream to be able to replace our use of Clang modules?" and "What is the cost of doing that?" and "What is the benefit of making that switch?" For other projects, adopting standard modules is a more straightforward calculus.
- pjmlp 5y ago
  Fair enough, thanks for the clarification.