iains added a comment. In D120540#3384644 <https://reviews.llvm.org/D120540#3384644>, @ChuanqiXu wrote:
> @rsmith told me that the ideal situation would combine C++20 modules and > clang modules together in D113391 <https://reviews.llvm.org/D113391> Maybe I understand something slightly different; that we should migrate to a situation where compiling C++ code //**with no other contradicting options**//, would produce C++20 modules. Preferably, for most users that means no special options would be needed for the standardised modules. > I think the most important thing here is to get in consensus for the module > status. Here might be some helpful questions for the goal: > > - Should C++20 modules and Clang modules be exclusive from each other? > - If yes, we could take the idea ` -fmodules= {clang, c++20, none...} ` and > forbid the combination of `-fmodules -std=c++20`. And we could use variable > `Modules` to indicate clang modules and `CPlusPlusModules` to indicate c++20 > modules. > - If no, it implies that we could use c++20 modules and clang modules > together. So the combination of `-fmodules -std=c++20` or even `-fmodules > -fcxxmodules` makes sense. It implies that we could use the grammar of clang > module extension or c++20 modules. This is decision from D113391 > <https://reviews.llvm.org/D113391>. Here are some further questions: In my input, there was no intention to forbid `-fmodules -std=c++20`, quite the opposite (it would be OK). I am suggesting that the presence of `fmodules` on the command line would be a statement that the user wanted `clang modules` (and that would be perfectly OK in conjunction with C++20). ... But that would switch off C++20 modules mode because there are incompatibilities at present (in particular it means treating headers differently - and possibly sub-module visibility). There might come a time when clang modules are identical to C++20 ones, but I could imagine that would be some considerable time in the future - because end users would have to migrate. > - Would it be very hard to implement or maintain? once we have a firm plan for which things are allowed together it is not hard to maintain - what is hard to maintain is a situation in which we are not sure of exactly what we should be producing ... > - We lack a variable to indicate clang modules only. Currently, we couldn't > use `Modules` to indicate clang modules since `Modules` is true if we turned > C++20 modules on. `Modules` indicate either clang module or c++20 module is > enabled. Or we could think it means the common parts of the two features. we could make such a variable easily - if the decision was made to do it (what could be a little harder is to separate out the modules command line options into mutually-exclusive groups). > The most important technical question might be `Would it be very hard to > implement or maintain?`. From my experience, I think it is implementable. But > I **feel** it is not easy to maintain. We don't have the experience since > C++20 modules are not in the state of maintaining now. > > I don't have strong opinions for the concrete decision. But I think it is > very important to get in consensus. @iains @Bigcheese In this processes, I am not a major stakeholder - just an interested party as a coder and user - the call is down to @rsmtih and @Bigcheese. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D120540/new/ https://reviews.llvm.org/D120540 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
