I see several issues with translating Fortran to C++. The most fundamental is that Fortran has concepts and capabilities that C++ lacks (of course, the reverse is true too). A significant example is single-program, multiple-data (SPMD) parallelism with a partitioned global address space (PGAS) that both work in distributed memory. The closest analogous C++ concept might be multithreaded programming, but that only works in shared memory and one would need to fork all threads at the beginning of execution, handle several setup tasks (e.g., establishing non-allocatable coarrays), not join the threads until the end of execution, and prevent the spawning of additional threads by individual loops – and that’s just a small sampling of the issues that would need to be addressed. One could translate the SPMD and PGAS features to one-sided MPI, but that’s going to be challenging to get right, less readable, and is likely to be hurt performance.
Then there’s a lot of information loss involved. Think about the long list of constraints that apply to pure procedures. Unless there’s a similar C++ concept, the reader of the translated code will have to read through each translated pure procedure to rediscover all the information that the single keyword pure provides in one fell swoop. Such rediscovery becomes especially important if the procedure gets called inside a parallel loop when translated to C++. By contrast, every procedure called inside Fortran’s do concurrent construct must be pure according to the Fortran standard.
Moreover, even though C++ now has multidimensional arrays, C++ still lacks array statements as far as I know. So are all array statements being converted to nested loops? If so, there again is a loss of information unless those are C++ parallel_for loops in order to retain the information that there is no implied ordering of iterations. Even then, it’s likely to lead to code bloat wherein what was one line in Fortran could become many more lines in C++.
And the languages are only continuing to diverge. Fortran 2028 templates will be type-safe – something that is not easily expressible in C++ because C++ doesn’t allow for specifying template requirements (relationships between types, procedures, and combinations thereof) so the loss of information could also lead to a loss in type safety if Fortran programmers take full advantage of the upcoming template feature.
I’ve only scratched the surface above. How about the fact that C++ allows overloading operators but does not facilitate user definitions of new operators. A common response is that user-defined operators are syntactic sugar, but such statements ignore the additional semantic constraints involved such as the requirement that the operands have the intent(in) property. That’s information the reader immediately knows when seeing the use of a user-defined operator in Fortran, whereas one would have to inspect the signature of every C++ function that replaces a Fortran operator to discover this same information about the arguments. And then there’s the argument that syntactic sugar can be exceptionally powerful in its communicative value.
There’s so much more that can be said about such topics as the differences between Fortran pointers and C++ pointers, e.g., target communicates important information to both the reader and the compiler. How will this information be communicated to the C++ compiler or developer?
Bottom line: the two languages are equivalent only in a superficial way that ignores a lot and accepts a considerable about of information loss, extreme restrictions, code bloat, and potential loss of safety and performance.