(j3.2006) (SC22WG5.4825) [ukfortran] J3/12-nnn J3 interpretations letter ballot #26 after meeting 198 - due 12-Oct-2012

[Van Snyder]

On Fri, 2012-10-12 at 16:22 -0700, Robert Corbett wrote:
> On 10/09/12 19:25, Malcolm Cohen wrote: 
> >  
> > R602 variable is designator or function-reference
> > C602 (R602) function-reference shall have a data pointer result.

> > Note that a less extreme viewpoint would be to allow the operator
> > syntax except as the variable in an assignment statement (or READ
> > statement).  That would be a better solution than the nitpicky
> > syntax tweaks that are the current proposed solutions to this interp
> > and the next, but would not be as consistent as disallowing this
> > problematic syntax entirely.


> Rafix Zurob's proposal in meeting 199 was similar to this proposal.
> The problem we identified then was that the change made in Fortran
> 2008 has been integrated into the standard in more than one place.
> For example, in Fortran 2003, the statement
> 
>       P => Q + 1
> 
> where the operation Q + 1 returns a pointer to a data object is
> permitted.

It is more likely that "call sub ( q + 1 )" will appear, where "q+1" has
a pointer result and the associated dummy argument does not have
INTENT(IN).  This was the original motivation for the change.

> If only the change suggested is made, that statement will not be
> permitted in Fortran 2008.  There are decisions that will have to be
> made regarding the ASSOCIATE and SELECT TYPE statements.
> 
> Robert Corbett

We did perhaps go a bridge too far, but at this stage I prefer only to
give interpretations to ambiguities, not to remove the syntax altogether
just because it causes ambiguity in a few circumstances.

I prefer the solution advocated in 12-149/150 and above by Malcolm, or
the alternative advocated by Malcolm:

C713a (R732) If <variable> is <expr> and not <designator>, it shall be a
<function-reference> that has a pointer result.

C932a (R916) If <variable> is <expr> and not <designator>, it shall be a
<function-reference> that has a pointer result.

Thee first solution precludes the possibility to reference a function
with a pointer result as an actual argument that corresponds to a dummy
argument that does not have INTENT(IN).

The alternative is a tiny bit risky.  Are we absolutely sure there are
no other syntax ambiguities?  I looked at every instance of <variable>
mentioned in the index, and didn't find one, but did find what appears
to be a problem with the data statement.

Is "data f(g) / 20 /" allowed, where "f" has a pointer result?  How
about "data q+1 / 42 /"?  I hope not, but I can't find where they're
prohibited?  Maybe we need

C565a (R536) The <variable> shall be <designator>. Or
C565a (R536) The <variable> shall not be a function reference.

-- Van