(j3.2006) Some Questions About Function Returnign a Pointer is a Variable (Was:: READ unit ambiguity)

[Craig Dedo]

> -----Original Message-----
> From: j3-bounces at j3-fortran.org [mailto:j3-bounces at j3-fortran.org] On Behalf Of
> Bill Long
> Sent: Thursday, March 01, 2012 07:40
> To: fortran standards email list for J3
> Subject: Re: (j3.2006) READ unit ambiguity
> 
> On 3/1/12 3:17 AM, Malcolm Cohen wrote:


	<snip>
> > Nice one. In Fortran 90-2003 this is standard-conforming:
> > (unit).op.666 is the unit specifier.
> 
	<snip>
> 
> > In Fortran 2008 we have added an ambiguous parse to the statement so
> > by clause 1 the program is not conforming.
> >
> 
> Assuming that UNIT is a variable or named constant valid for a io-unit, there is a
> problem that needs fixing.
> 
> I've now lost track of how many times the new "function reference returning a
> pointer is a variable" has caused bad side effects in the standard.  "Cool" ideas
> sometimes seem to have grief / benefit ratio that are higher than expected.
> 
> Cheers,
> Bill
> 
> > That was unlucky. We need to do something, even if that is just adding
> > another incompatibility to the list in clause 1. Other fixes are
> > possible - e.g. forbidding the first item of an input-list from
> > beginning with an operator (this would resolve the ambiguity in favour
> > of maintaining backwards compatibility).
> >
> > Cheers,
> 
> --
> Bill Long                                           longb at cray.com
> Fortran Technical Support    &                 voice: 651-605-9024
> Bioinformatics Software Development            fax:   651-605-9142
> Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

	The new rule, "function reference returning a pointer is a variable", seems like a
Really Bad Feature, more like a defect that needs fixing.  I have a few questions.

	I tried looking up "function reference returning a pointer is a variable" in the
Fortran 2008 standard and I could not find it.  Where is this defined?  

	How difficult would it be to reverse out this abomination?

	How many compilers have already implemented this "feature"?

	How many programs or users depend on it?  How difficult would it be for them to
change their programs if this "feature" was reversed out?

	What were the perceived benefits of this "feature"?  From my perspective, it
appears to have few, if any, benefits and a very large number of complications.

Sincerely,
Craig T. Dedo
17130 W. Burleigh Place
P. O. Box 423                         Mobile Phone:  (414) 412-5869
Brookfield, WI   53008-0423    E-mail:  <craig at ctdedo.com>
USA
Linked-In:  http://www.linkedin.com/in/craigdedo