On 8/30/19 2:52 PM, Ben Craig via SG15 wrote:
> Let’s try to enumerate the costs and benefits of adding source
> suffixes.  I want to avoid the conversation getting stuck on one side of
> that equation.
>
> What becomes easier with one or more additional source file extensions?
>
> * A build tool could look at the source file extension and make a high
> quality guess about which tools should be used on the file, and what
> artifacts will be produced by running that tool.
> o For example, a build system could look at a .h file and not run
> the compiler on it.  It could look at a .cpp file and run the
> compiler on it and expect a .o file output.  It could look at a
> .cppm file and run the compiler on it and expect a .o and .bmi
> file as outputs.
> o Globbing build systems would like to know which extension(s) to
> use in the globs that will eventually be fed into compiler
> invocations
> * A person could look at the source file extension and make a high
> quality guess as to what kind of thing is in that file.  Some people
> will want to be able to tell whether a file contains a primary
> module interface, a module partition implementation, or a
> traditional textual header, all from looking at the extension.
> * A file extension could indicate which files provide module
> interfaces, making it easier for a scanner to find those things
> o Note that this isn’t that big of a deal, because a build-time
> scanner is probably going to need to scan everything to see who
> consumes what.
> * Whatever else I’m forgetting.  Reflector, fill in this spot
>
> What becomes harder with one or more additional source file
> extensions? Are there mitigations?
>
> * Some build systems take the input file name and generate and output
> file name by replacing the source file extension with the
> destination file extension.  For example, foo.cpp -> foo.o. If we
> have multiple file extensions that produce a .o, then we will have
> conflicting output files.
> o Mitigation: Don’t perform foo.cpp -> foo.o.  Instead perform
> foo.cpp -> foo.cpp.o.  CMake and some other build systems do this.
> o Complication: Some compilers don’t let you choose the name for
> some output files
> * Text editors and IDEs that don’t recognize the new extension may
> incorrectly colorize, auto-complete, and indent code.
> o Mitigation: Most text editors let you customize which extensions
> map to what language
> o Complication: The editors would benefit from updates to
> understand the rest of C++20 anyway, including all the new keywords.
> * Dialogs like “Add File…” and “Open…” may not show files with the new
> extension by default
> o Mitigation: There’s usually an option in the dialog to show all
> files
> * Migrating code from a text header to a module interface requires (or
> at least strongly encourages) a file rename
> o Complication: If your build system also does extension
> replacement (instead of appending a new extension), then you may
> also need to change the file base name.
> * Compilers, and some other multi-language tools make guesses about
> what language a source file is based off of the extension.  These
> tools need to be taught the new extension.
> o Mitigation: Most of these tools can be told specifically the
> language of a source file.
> * Whatever else I’m forgetting.  Reflector, fill in this spot

This is putting the cart before the horse. First list the requirements
that are trying to be achieved.

There are other ways to achieve the 'becomes easier' items than a new
file extension. All the 'becomes harder' items are adding friction.

nathan

-- 
Nathan Sidwell