On 4/13/22 17:10, Nico Josuttis via SG15 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.

I shall correct you :)

Here's the history (as I recall, all persons mentioned are real, and not to be
confused with ficticious characters)

* prior to me doing things with gcc, there was only 'module FOO;' as a module
declaration at-most once within a TU. MSVC (the only compiler with module
smarts at the time), had a flag to tell it 'this is an interface' vs 'this is an
implementation'.

* I found this unsatisfying, as it meant that there was something outside the
source tokens that told you how to interpret them. In effect we had two languages.

* IIRC, Gaby, Jason (Merrill) and I came up with the 'export module FOO;' vs
'module foo;' distinction. But still this could be anywhere in the source
stream. I was able to implement this functionality to a working system.

* Daveed proposed an early signifier of 'hey, this is gonna be a module', should
the actual module declaration not be first. Hence 'module;' was born. (My
understanding was that this was driven by implementors, as they had difficulty
entering a module-like mode not at start of compilation, and indeed it was a
little tricky to do that. I do not know if this was also a user request.)

* post p1103, the requirement that everything between 'module;' and the module
decl come from #include came to be.

Hope that helps.

I know I've mentioned it more than once, but I find it unsettling, given there
was great opposition to there being a (two way?) mapping between file names and
module names, that there is a move in the direction of making file names
'significant'. ISTM that the desire for bob.$REGULARSUFFIX and
alice.$MODULESUFFIX is taking us all the way back to the first objection above
about having two languages.

nathan

>
>
>
> Am 13. April 2022 22:58:13 MESZ schrieb Nicolai Josuttis via Ext
> <ext_at_[hidden]>:
>
> 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.
>
> 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?*
>
> I understand that a suffix discussion is only of practical value.
> But IMO the standard has to give an answer here (which has nothing to do
> with which suffixes are used).
>
> Let me elaborate that in detail:
>
> Not having a standard suffix has interesting consequences.
> So far we have header files and translation units.
> But once we know what a C++ translation unit is, we can just compile them
> all with the same compiler options or commands. Because in practice we have
> different suffixes for header and source files, we can set-up generic rules
> to compile our code.
>
> This works for any suffix, provided you know the way to tell the compiler
> that we have a C++ file here:
> (use /Tp with VC++ and -xc++ with gcc and you are done).
>
> 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?
>
> 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.
>
> - *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
>
> I wonder whether the behavior of VC++ is standard conforming.
>
> I see no place in the C++ standard saying that there has to be different
> treatment of C++ source files to make them work.
> Or do we require this somewhere?
> We do not require different treatment just because we have templates,
> namespaces, or exceptions used inside.
> Therefore, I would expect that also using modules does not require special
> handling.
> (This is independent from the question whether different suffixes help to
> deal with these files).
>
> If I am right, VC++ is not standard conforming.
>
>
> In any case it would help a lot to clarify:
> Can all C++ source files expect that treating them the same way works fine?
>
> If not, we obviously need different suffixes. But then we should clearly say
> so (without necessarily saying which suffix it is).
>
>
> I hope this questions brings us a bit forward to be able teach the first
> *portable *"hello, modules" example.
>
> Thanks
>
> Nico
>
> --
> ---
> 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
>
> --
> Nico Josuttis
> (sent from my mobile phone)
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15

-- 
Nathan Sidwell