Question

I am somewhat puzzled by the following program

module test
   implicit none

   type TestType
      integer :: i
   end type

contains
   subroutine foo(test)
      type (TestType), intent(out) :: test
      test%i = 5 
   end subroutine

   subroutine bar(test)
      type (TestType), intent(out) :: test
      test%i = 6 
   end subroutine

end module

program hello
   use test
   type(TestType) :: t

   call foo(t)
   print *, t%i 
   call bar(t)
   print *, t%i 
end program hello

and its derivatives. More on those later. As we know, Fortran transfers routine arguments as a pass-by-reference, meaning that the entity emerging at the dummy argument test for both foo and bar is the same memory space granted on the stack in program hello. So far so good.

Suppose I define in program hello the type(TestType) :: t as a pointer, and allocate it.

program hello
   use test
   type(TestType), pointer :: t

   allocate(t)

   call foo(t)
   print *, t%i
   call bar(t)
   print *, t%i

   deallocate(t)
end program hello

The code works as before, the only difference being that the object was not allocated on the stack, but on the heap.

Now assume to go back to the stack-allocated program and that subroutine bar is instead defined as

 subroutine bar(test)
    type (TestType), pointer :: test
    test%i = 6 
 end subroutine

The program does not compile anymore because you must use the heap-allocated version to make it work, or to be more accurate it is mandatory to pass a pointer to the routine when the routine is defined to accept a pointer as a dummy argument. On the other hand, if the dummy argument does not contain the pointer keyword, the routine would accept both pointers and non-pointers.

This makes me wonder… what’s the point of declaring a dummy argument a pointer ?

Answer 1

Reposted from comp.lang.fortran, an answer by Tobias Burns:

Now assume to go back to the stack-allocated program and that
subroutine bar is instead defined as

subroutine bar(test)
type (TestType), pointer :: test
test%i = 6
end subroutine

The program does not compile anymore because you must use the
heap-allocated version to make it work,

That’s not quite correct: You can also not pass an ALLOCATABLE variable
to a dummy with POINTER attribute. I think one (practical) reason is
that the pointer address can escape and you would thus cause alias
problems. A formal reason is that an ALLOCATABLE is simply not a
POINTER; additionally, the standard does not talk about heap vs. stack
vs. static memory. And in fact, local arrays [with constant bounds] will
often be created in static memory and not on the stack (unless you use
OpenMP or the RECURSIVE attribute). Thus, your “stack” example could
also be a “static memory” example, depending on the compiler and the
used options.

or to be more accurate it is
mandatory to pass a pointer to the routine when the routine is defined
to accept a pointer as a dummy argument.

That’s also not completely true. In Fortran 2008 you can pass a
non-POINTER, which has the TARGET attribute, to a pointer dummy which
has the INTENT(IN) attribute. (Pointer intent is relative to the pointer
association status; for non-pointer dummies the intents are about the
value stored in the variable.)

This makes me wonder… what’s the point of declaring a dummy argument
a pointer ?

Well, if the argument has the POINTER attribute, you can allocate and
free the pointer target, you can associate the pointer with some target
etc. Up to Fortran 95 it was not possible to have ALLOCATABLE dummy
arguments thus a pointer had to be used if a (dummy) argument had to be
allocated in a procedure.

If you can, you should try to use rather ALLOCATABLEs than POINTERs –
they are easier to use, do not leak memory and have pose no
alias-analysis problems to the compiler. On the other hand, if you want
to create, e.g., a linked list, you need a pointer. (Though, for a heap
usage, also Fortran 2008’s allocatable components could be used.*)

*I mean:
   type t
       type(t), allocatable :: next
   end type

where the component is of the same type as the type being defined;
before F2008 this was only allowed for pointers but not for allocatables.

and by R. Maine

As we know, Fortran transfers routine arguments as a
pass-by-reference,

We apparently know incorectly, then. The standard never specifies that
and, indeed goes quite a lot out of its way to avoid such specification.
Although yours is a common misconception, it was not strictly accurate
even in most older compilers, particularly with optimization turned on.
A strict pass-by-reference would kill many common optimizations.

With recent standards, pass-by-reference is all but disallowed in some
cases. The standard doesn’t use those words in its normative text, but
there are things that would be impractical to implement with
pass-by-reference.

When you start getting into things like pointers, the error of assuming
that everything is pass-by-reference will start making itself more
evident than before. You’ll have to drop that misconception or many
things wil confuse you.

I think other people have answered the rest of the post adequately. Some
also addressed the above point, but I wanted to emphasize it.

Hope this answers your question.