Cppcoreguidelines: SF.1 better to state .hpp as well as .cpp

[jonnygrant]

There is an old discussion that is closed:

https://github.com/isocpp/CppCoreGuidelines/issues/442

Could .hpp be considered for header files, it doesn't make sense to have the same extension for two different languages. For a library with an interface.h and interface.hpp it makes it clear which are C++

Seems like a bad idea to leave file extensions to particular projects discretion. Other languages have standard extensions.

But anyway, it would be good if there was an official standard convention to standardise around (the C++ spec doesn't even state .cpp !)

Even any .cxx or .C files which are actually C++ code could easily be renamed in projects for future releases of their codebases. Worked on many projects that have renamed files between releases.

[hsutter]

Editors call: Thanks! We agree not to ban .hpp (or .hxx), just like we don't ban the .C and .cxx that are popular in some projects for C++ source. SF.1 does say "But consistency is more important, so if your project uses something else, follow that." We feel that covers .hpp reasonably for now. We don't want to inadvertently create a reason for someone to say 'we should convert our 1,000 header files to .hpp because the Core Guidelines say so.' Also, we look forward to modules' making headers gradually less important over time.

[jonnygrant]

Thank you for your reply. I won't keep beating the drum, but feel it should simply say:

"SF.1: Use a .cpp suffix for code files and .hpp for interface files if your project doesn’t already follow another convention"

That allows all the old .h and .C files etc to carry on working, as you say

[MikeGitb]

We don't want to inadvertently create a reason for someone to say 'we should convert our 1,000 header files to .hpp because the Core Guidelines say so.'

In all seriousness: Why not? It's not like you are forcing anyone.

Also, as you said in https://github.com/isocpp/CppCoreGuidelines/issues/1393

The Guidelines' current default is to say "these are Guidelines intended for modern code written in an encouraged style." In existing code, they can't easily be adopted wholesale by an existing project (unless the Guidelines were toothless and not really providing much value) and so will generally need to be adopted incrementally.

If someone actually pays attention to the recommendation at all, new files can use hpp and old files can continue to use h or changed incrementally.