C++ file extensions aren’t standardized unlike other languages. Hence the need for keywords to enable functionality.

So you can’t really rely on extensions to be sufficient.

Many build systems and compilers do assume specific extensions imply a file type by default, but those can often be configured to arbitrary extensions as well.

Existing C++ file extensions aren't standardised. There's no reason they couldn't mandate file extensions for this.

And really even among the non-standard extensions it's like 95% .cpp, 4.9% .cc and 0.1% .c++. Ignoring the weirdos it's de facto .cpp or .cc. They could standardise that too if they really wanted and there was a benefit.

This sounds like one of those things that often happens where people worry about technically possible but totally insignificant risks, and insist on handling them because they feel proud of having thought of them.

Not enough YAGNI.

You’re missing cxx and mm, which are more common in codebases I deal with than most of your examples. Which is to say you can’t make sweeping statements.

Anyway, I’d try and contextualize your argument more by adding that feature teams are restricted in the scope of the changes they can do to the features they’re working on. They can certainly suggest that the language specify specific extensions but that goes against decades of convention, and is a hill that would likely have taken more of their time and energy for little specific gain for the feature itself.

I’m not arguing that there shouldn’t be standard extensions, just that I can understand why it didn’t happen. It’s like swimming upstream

Ah yes `.cxx` is rare but used. I haven't seem `.mm` for decades. IIRC gtkmm uses that? No maybe not, they use `.cc`. What on earth uses `.mm` now?

Anyway none of that really changes the point - they could easily standardise extensions. The only reason they haven't is because there has been no real benefit until now.

cxx is what msvc prefers hence why they picked icxx for their module types.

mm is convention for ObjC++ files, which is a required dialect if you need to use most the platform libs on Apple platforms.

Being the standard extensions for the two most major platforms, I wouldn’t call them rare at all.

And which further reinforces my point. They could have mandated an extension BUT it would have been going against convention which makes it decidedly not easy. There’s not one singular team in charge and there’s lots of friction in such a seemingly minor change.

I’d argue too that even with modules there’s very minimal benefit to a standard extension. Any such benefit would have had even greater benefit for the rest of the language.

You forgot .cxx

What .ii for preprocessed files? And .ipp and .tpp for template implementation files?

The implementations have no agreement here. Clang "likes" `.cppm` while MSVC "likes" `.ixx`. I don't think there's any hope for agreement on extensions.

Part of the justification is the lack of optimism that file extensions could be mandated (I'm less pessimistic).

But it's also an important hint to the preprocessor to make pre-build dependency scanning faster. You don't want to have to compile all possible source files and then throw a bunch of that work away once you find there are module dependencies in the source files. Just having a magic file extension is not enough to clarify that.

A C++ packaging standard could help there, but C++ started with modules, probably because they seemed simpler.

There should not be a c++ standard for packages. Maybe an ISO standard, but it needs to work for all languages, otherwise we will all roll our own. If the package can't support all languages it doesn't support the complex world C++ is used in.

There is some work in that direction but no specific ISO proposals yet.

It is a very hard problem. I'd be concerned if there was a proposal.

That is only if you have a global module fragment. Without that, you can start right off with `export module M;`.