(j3.2006) Disassociated array pointer actual argument corresponding to an optional argument of elemental procedure.
Tue Dec 9 21:00:00 EST 2014
On Wed, 2014-12-10 at 00:36 +0000, Bill Long wrote:
> On Dec 8, 2014, at 3:05 PM, Malcolm Cohen <malcolm at nag-j.co.jp> wrote:
> > 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!
> Certainly it is undesirable for the above to be a valid alternative,
> but absent a restriction otherwise it is the logical consequence of
> the idea that the new forms of an actual argument being not present
> should be semantically the same as the actual argument being
> textually absent.
> I agree with Daniel?s observation that modifying (6) directly is the
> wrong context. We?re talking about a restriction on disassociated
> pointers, not on optional arguments not present. The analog of (1) in
> the same paragraph, except for disassociated pointers, is in 2.4.8p2.
> However, I think it would be more relevant to have the restriction in
> 22.214.171.124. Perhaps a new paragraph 5 for that subclause what says
> directly what we want:
The only cases in which a disassociated pointer is allowed to correspond
to a dummy argument are those where the dummy argument is a pointer, or
optional. The POINTER case is prohibited by C1289.
Therefore, the only case that needs attention is the concerning optional
arguments, for which 126.96.36.199p3(6) would work if the restriction
started with the dummy argument and worked backward to the actual
> "A disassociated array pointer 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."
> > 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.
> > _______________________________________________
> > J3 mailing list
> > J3 at mailman.j3-fortran.org
> > http://mailman.j3-fortran.org/mailman/listinfo/j3
> Bill Long longb at cray.com
> Fortran Technical Suport & voice: 651-605-9024
> Bioinformatics Software Development fax: 651-605-9142
> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
> J3 mailing list
> J3 at mailman.j3-fortran.org
More information about the J3