warning #6717: This name has not been given an explicit type

[mic_esp96]

Hi everyone,

I am making use of submodules in order to separate implementation details.

However, without intent, I came up to something that looks really strange to me. At some point, in one method implemented in the submodule, I had:

1. mispelled a private variable of the parent module.
2. forgotten to declare a local variable (in the same procedure).

I give you a quick example:

module parent

   implicit none
   private

   integer :: my_var_

   interface 
      module subroutine do_smt(a1, a2)
         integer, intent(in) :: a1, a2
      end subroutine
   end interface
end module



submodule(parent) implem

contains
   module subroutine do_smt(a1, a2)
      integer, intent(in) :: a1, a2

      itmp = a1 + a2
      itmp = itmp * itmp

      my_var = itmp
   end subroutine
end submodule

For both of them, I was expecting to have an error of undeclared type variable. On the contrary, I had a warning: 

warning #6717: This name has not been given an explicit type.   [ITMP]

Why? Is there an explanation?

Thanks,

Michele

[FortranFan]

@mic_esp96 ,

Intel Fortran compiler is lenient that way!

By the way, you need MODULE prefix to the subprogram, whether a subroutine or a function, whose implementation is deferred to a submodule e.g., module subroutine do_smt(a1, a2) ..

[mic_esp96]

@FortranFan ,

thanks for the suggestion, clearly I forgot to add it while writing the example above. But of course, it existed in the "real" example.

For the issue itself, I see. Wouldn't it be better to turn it into a compiler error in future releases? Clearly it would avoid many runtime errors, and save tons of time in order to find them (in large code bases), if warnings are disabled.

[FortranFan · Accepted solution]

@mic_esp96 ,

TL;DR: you need "implicit none" in your submodule 'implem' also.  And consider the compiler options of /warn and /warn:errors if you feel brave enough with your codes.

Re: "Wouldn't it be better to turn it into a compiler error in future releases? Clearly it would avoid many runtime errors, and save tons of time in order to find them (in large code bases), if warnings are disabled."

• below is my long rant with the situation.

What I meant by "lenient" was me being entirely vague and simply awful for holding the following thoughts (which, by the way, I do think is the truth, bitter and hard that it often is but these days mere thoughts can be crimes):
* first note the implicit mapping scheme in Fortran whose legacy began with IBM FORTRAN I circa 1950s: the objects whose names start with I, J, K, L, M, N shall be default integer types unless declared otherwise and objects whose names with any letter beside the previous six i.e., A thru' H and O thru' Z are of default REAL types unless declared otherwise.

* now note SUBMODULEs were introduced in Fortran in the 2008 standard revision at which point there was only, oh about THIRTY years of realization the above implicit mapping scheme is increasingly pernicious and that the practitioners need to and they do also strive to override this nasty, nasty mapping scheme with explicit "IMPLICIT NONE" statements everywhere,

* then with the 2008 standard revision the absolutely horrible, horrible decision was made the implicit mapping scheme in the new-fangled feature, one that NONE of the dusty desk writers and their codes would see in a million years, would have the same implicit mapping scheme.  Meaning: the SUBMODULEs shall be a program unit on its own and have its own implicit mapping scheme by default and NOT "inherit" the one from its PARENT MODULE.

* then compiler vendors have somehow concluded to generally go by the standard, but rarely above and beyond it for the sake of newer practitioners of Fortran, and also what their "BIG" customers supposedly want which is supposedly also the demands of their dusty deck maintainers, who compile and run the same "old codes"  with few or no changes with newer compiler versions, or at least none when it comes to default implicit mapping.  Thus a newer compiler such as Intel Fortran version 202X.Y even continues to treat the implicitly typed objects GENTLY, it only hands out benign warnings when the user has asked for them with /warn option.  This is the case even when the scope is a SUBMODULE, a new-fangled thingy where practically every user of it will want `implicit none`!  So if a compiler were to truly care of its customers and truly desired for product stewardship, a newer program unit such as SUBMODULE will be seen to have implicit none as default even if the standard didn't call for it.  But to do so will be too much effort on the part of the front-end writers, you know they to have to somehow distinguish the scope is SUBMODULE as opposed to, say, an external subprogram, such as free-standing function or subroutine which is the stuff of dusty decks and where the maintainers would supposedly go ballistic if "implicit none" were to become the default. 

* Similarly a global change for the compiler, to treat implicit none as the default everywhere when it comes to issuing error messages to help the users would supposedly render UNHAPPY the "BIG" customers.  And that this is the case even after FORTY PLUS years of knowing implicit typing can be very harmful,

* Thus a warning it shall remain with Intel Fortran when it comes to implicitly typed objects, as you saw with your ITMP object..  Note that too gets issued only when /warn compiler option is in effect.

* Fortran is retaining itself in a bad place with so many issues but it is compounding its problems and the bad image with its mind-boggling insistence on sticking with the harmful effects of `implicit mapping` even with newer changes to the language.  It is hemorrhaging support among so many domains as a result.  A statistically insignificant amount of new apps, even in scientific and technical computing, select modern Fortran components, let alone as a primary language of choice.  As the latest survey of programming languages by IEEE Spectrum shows, Fortran is virtually a dead language now with a near-zero ranking (around 0.59) even among the engineers who would be interested in floating-point computations, traditionally a forte of Fortran:

https://spectrum.ieee.org/top-programming-languages-2022  

[mic_esp96]

@FortranFan ,

thanks for this exaustive answer !! Was a pleasure to read it!

Re: "* first note the implicit mapping scheme in Fortran whose legacy began with IBM FORTRAN I circa 1950s: the objects whose names start with I, J, K, L, M, N shall be default integer types unless declared otherwise and objects whose names with any letter beside the previous six i.e., A thru' H and O thru' Z are of default REAL types unless declared otherwise."

• I surely knew about it, but...

Re: "* then with the 2008 standard revision the absolutely horrible, horrible decision was made the implicit mapping scheme in the new-fangled feature, one that NONE of the dusty desk writers and their codes would see in a million years, would have the same implicit mapping scheme.  Meaning: the SUBMODULEs shall be a program unit on its own and have its own implicit mapping scheme by default and NOT "inherit" the one from its PARENT MODULE."

• THIS IS EXACTLY WHAT I HAD GIVEN FOR GRANTED... but of course being wrong.
  Though, it seemed the most intuitive things about submodules (since they inherit everything parent module, I thought so they did for 'implicit none').

Re: " [...].  This is the case even when the scope is a SUBMODULE, a new-fangled thingy where practically every user of it will want `implicit none`! [...]"

• Exactly that, I don't see why old implictly typed units might be affected by the introduction of submodules, since everyone that would employ them, is almost 100% likely to use 'implicit none'.

[Steve_Lionel]

That warning about implicit type is given only if you use /warn:declarations - you get an error if you use implicit none (already noted). It is not that the compiler is lenient, but that implicit typing is still a part of the language, as FortranFan notes.  There are some (including FF) who want to remove that feature in the next standard revision, but more likely would be that implicit typing is added to the "obsolescent" list. This would require that compilers have the ability to warn you of implicit typing, but it is still part of the language. Theoretically, it could then be deleted in a subsequent revision, though I'd expect a lot of objections to that. Even if deleted, compilers would still support the feature as an extension.