The IMPLICIT NONE issue drags on

[Andrew_Smith]

It is good practice to use IMPLICIT NONE but it is hard to enforce because one has to pepper code with IMPLICIT NONE and when you miss one, there is nothing to tell you unless you use a non-standard compiler directive.

The standard should make life easier for us by making good things the default when it does not break old code. Module procedures is new so the standard could have been better in this area.

This code raises no errors. You can add IMPLICIT NONE to all the module procedure interfaces but it can be an onerous task.

We dont need an IMPORT statement in the module procedure interface because this special type of interface picks up the scope of the module. Since the parent module has IMPLICIT NONE, the module interfaces should see this.

Is this a correct interpretation of the standard and if not why was the standard lacking in this area?

module A

   implicit none
   
   interface
      module subroutine foo(X)
      end
   end interface

end module

[FortranFan]

Steve Lionel (Ret.) wrote:

A problem here is that there is no INTENT specifier equivalent to omitting INTENT. It isn't the same as INTENT(INOUT), in that the latter requires that the actual argument be definable, whereas omitting intent does not. I plan to propose for F2020 something like INTENT(UNKNOWN) or (OMITTED) to rectify this. Without such a feature, you can't ask a compiler to mandate INTENT.

Trying to include "something like INTENT(UNKNOWN) or (OMITTED)" in the standard seems like needless clutter.

The suggestion here is not for "a compiler to mandate INTENT" but only to act as a static analysis tool to report a warning when requested during compilation of code where explicit interfaces are on evidence and INTENT is not included for any dummy argument.

Document N2137 toward Fortran 2015 in section 8.5.10 on INTENT attribute has on page 108:

5 If no INTENT attribute is specified for a dummy argument, its use is subject to the limitations
  of its effective argument (15.5.2).

There are more than enough indicators in section 15,5,2 on Actual arguments, dummy arguments, and argument association that a processor which strives to follow the "spirit" of the standard will know when no INTENT attribute is specified for a dummy argument.  The idea is to just issue a warning when such a situation is noticed by the compiler and that too only when asked.  I don't see a need to touch the standard on this aspect.

[Steve_Lionel]

It is a cardinal rule of user interface that you should always be able to explicitly specify whatever the default is. I can't think of another place in the language where you can't.

[garylscott1]

Well, I think it is inconsistent that you can specify the VALUE attribute but you can't specify the REFERENCE attribute.  For self documenting code, it is important to me to be able to specify this attribute...when I'm defining an interface to another language.  I never have a need in my own code, but I vastly prefer to fully define the expected behavior through self documenting code (yes I can add a comment, but that's kludgy.  I've mentioned this before, but the response has been usually to poo poo it with the "fortran always passes by reference" silliness.

[Steve_Lionel]

The VALUE attribute is complex, and changes its meaning completely if the procedure is interoperable. For a procedure without a language-binding-spec, VALUE does NOT mean "pass by value", and the standard goes out of its way to indicate that "reference" is not really the default:

Fortran argument association is usually similar to call by reference and call by value-result. If the VALUE
attribute is specified, the effect is as if the actual argument were assigned to a temporary variable, and
that variable were then argument associated with the dummy argument. Subsequent changes to the value
or definition status of the dummy argument do not affect the actual argument. The actual mechanism by
which this happens is determined by the processor.

[Emphasis mine.] Therefore, a REFERENCE attribute would be inappropriate. 

In the case of INTENT, this is information the user is supplying that doesn't change the semantics of the program, but it adds information that can be useful in diagnostics and optimization, as I wrote earlier.