(j3.2006) Disassociated array pointer actual argument corresponding to an optional argument of elemental procedure.

[Malcolm Cohen]

Hi Daniel,

>Is the following program standard conforming?
>
>
>      integer, pointer :: p1(:)
>      integer k
>
>      nullify(p1)
>
>      call sub1(p1, k)
>
>      contains
>      impure elemental subroutine sub1(arg1, arg2)
>        integer,  intent(inout), optional :: arg1
>        integer,  intent(in) :: arg2
>      end subroutine
>      End
>
>
>P1 is disassociated, but its extent is used to scalarize the elemental 
>procedure call. Is this code standard conforming?

No interpretation is established, so no.

>The only thing I found that is sort of relevant in the standard is [12.5.2.12: 
>p3: (6)]
>
>"An optional dummy argument that is not present is subject to the following 
>restrictions.
>...
>(6) If it is an array, it shall not be supplied as an actual argument
> to an elemental procedure unless an array of the same rank is
> supplied as an actual argument corresponding to a nonoptional
> dummy argument of that elemental procedure."
>
>Do we need something similar to this for the test case at the above?

I think we do.  It is clear that we did not intend to allow this.

Van suggests:
>I don't think we need something extra for this case, but item (6) ought to be 
>reworded

Rewording item (6) might well be the best way to fix it, but I do think it ought 
to be fixed rather than relying on a combination of "obvious intent" and the 
fact that allowing it does not make sense.

Bill suggests:
>The call should have the same effect as
>
>   call sub1 (arg2 = k)
>
>which is valid and results in a scalar call, since all of the actual arguments 
>are scalar.

This is completely without merit, since whether P1 is declared "INTEGER,POINTER" 
or "INTEGER,OPTIONAL" makes no difference to the way that optionality works. 
I.e. that argument applies precisely to the exact case that item (6) prohibits!

We prohibit that case for good reason, and one of those good reasons is that 
allowing it would make it trivial to construct a generic reference that could 
not be resolved at compile-time (because the rank of a function reference would 
depend on whether a pointer was associated).  Thus violating one of the 
fundamental principles of generic resolution.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.