Thanks a lot Ben,

oh yes, you are right.
You have to parse the C++ source file to find the real module declaration.

AFAIU, these would be the rules, right?:

*export module* /<name//*without*//colon> /

   identifies a module interface

*export module* /<name//*with*//colon>/

   identifies an interface partition

*module* /<name//*without*//colon> /

   identifies module implementation

*module* /<name//*with*//colon> /

   identifies an internal partition


Despite any convention, it would of course be best if compilers can
always check for that and do the right thing automatically (or at least
complain if the suffix does not fit with the content).
Unfortunately, this is not the case for VC++ yet (so you have to use
different suffixes for generic rules).

OK, but that is quality of implementation of a specific vendor.

For SG15, it would be great to agree that any suffix is possible and
that it should always be possible to have just *one command line to
compile all code* a C++ program using modules (unfortunately, Visual C++
currently does not allow both /interface and /internalPartition at the
same command line; but I have submitted a bug report).

Than we can the community let decide over time which suffixes they
prefer (yes, another mess created by us, but...).

BTW, what is the current state of recommended suffixes?

Do you now all agree on .cppm or .cppi or so (the most self-explanatory
suffix from clang; programmers shake heads about .ixx)?

If so, I really would like to document that as the way to implement
modules portably now.

As I am not party of SG15 (my time is limited), an answer also directly
to me would be great.

Thanks.

  Nico


Am 13.04.2022 um 23:44 schrieb Ben Boeckel:
> On Wed, Apr 13, 2022 at 22:58:13 +0200, Nicolai Josuttis via Ext wrote:
>> What I teach about modules is compelling. Programmers like and want to
>> use it.
>> However, they ask how they should organize module files in practice.
> <puts CMake hat on>
>
>> So far I cannot recommend a specific suffix (and I might never be able
>> to do that).
>> However there is one important question that IMO the standard should answer:
>> *Do we **/need /**different suffixes?*
> Need? No. Even with different suffixes, a scanner is still necessary to
> know what order files need to be compiled in.
>
>> Is this still true with modules?
>> That is: Can we expect that identifying a file as C++ file is enough to
>> be able to (pre) compile it as C++ file?
> I don't believe so. Ordering is important, so you might know what flags
> to pass, but you still need to know to compile `provides_x.cpp` before
> `imports_x.cpp`. I don't think the filename is the place to store such
> information, so you're left with scanning or luck IMO.
>
>> Current compilers give different answers (AFAIK):
>>
>> - *gcc *says the same suffix is possible. There is not special option
>> for modules.
>> I can still have my own suffixes and use -xc++ though.
> There is `-x c++-header` also when compiling header units (to get a BMI
> file). I believe Clang has some flags for its older module system that
> are relevant, but I haven't dealt with it that much (because I haven't a
> scanner for it yet).
>
>> - *VC++* currently requires different suffixes or different command-line
>> arguments.
>> Identifying a file as C++ file is not enough.
>> For example
>> - This is not enough: /Tp mymod.cppm
>> - You need: /interface /Tp mymod.cppm
> You also need `-internalPartition` to be able to tell:
>
> ```c++
> // Compile with `-internalPartition`
> module X:part; // non-exported module partition
>
> int f();
> ```
>
> apart from:
>
> ```c++
> // Compile without `-internalPartition`
> module X:part; // without the flag, this is now an implementation unit
>
> int f() { return 0; }
> ```
>
> There is no syntactic difference; it is purely metadata. AFAIK, this is
> not supported with GCC (one just uses `module X;` in the implementation
> unit regardless of the partition).
>
>> In any case it would help a lot to clarify:
>> Can all C++ source files expect that treating them the same way works fine?
> In CMake, the plan is that C++ code is C++ code. The variety of `.cppm`,
> `.ixx`, and other extensions have just extended what CMake considers as
> C++ code out of the box. But CMake also plans on scanning all C++
> sources to figure out what is going on anyways, so extensions aren't
> really that useful (in my personal opinion as a build systems guy).
>
> FWIW, CMake also allows someone to say that `.frob` is a C++ file by
> either amending the extension globbing variable or explicitly setting
> the source file's `LANGUAGE` property to `CXX`.
>
>> If not, we obviously need different suffixes. But then we should clearly
>> say so (without necessarily saying which suffix it is).
> Suffixes can help with flags, but not with ordering.
>
> On Wed, Apr 13, 2022 at 23:10:42 +0200, Nico Josuttis via Ext wrote:
>> I should add that the fact that we need
>> module;
>> at the beginning of the global module fragment was only introduced to
>> let a file identify itself as module file. If we would require
>> different suffixes, that would not have been necessary.
>>
>> But correct me if I am wrong.
> Not all files use that (e.g., I've yet to write `module;` in any example
> I've used at least).
>
> --Ben

-- 
--- 
Nicolai M. Josuttis
www.josuttis.de
+49 (0)531 / 129 88 86
+49 (0)700 / JOSUTTIS
Books:
 C++: http://cppstd20.com, http://cppstd17.com, http://cppmove.com,
      http://cppstdlib.com, http://tmplbook.com