(j3.2006) Did we intend to prohibit this?

[Van Snyder]

On Fri, 2017-03-10 at 23:59 +0000, Bill Long wrote:
> On Mar 10, 2017, at 5:17 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
> 
> > On Fri, 2017-03-10 at 17:12 -0500, Steve Lionel wrote:
> >> On 3/10/2017 5:00 PM, Van Snyder wrote:
> >>> According to 9.7.3.2p4, whatever the function result is, it must be
> >>> allocatable, or it couldn't be deallocated.
> >> 
> >> The difference is that the programmer is not in control of the 
> >> allocatable object once the function returns. As Tom says, you can see 
> >> the value, but don't have a handle on the allocation. The processor is 
> >> responsible for setting up the result variable as allocatable and 
> >> deallocating it when the statement completes. You don't get to do 
> >> anything to its allocation status or even reference it as if it were an 
> >> allocatable.
> >> 
> >> As Malcolm wrote, the purpose of this feature is to allow a function to 
> >> return an arbitrary-shape result, the shape of which is then used in the 
> >> context of the function's value. Once the function returns, the fact 
> >> that the result is allocatable is invisible to the programmer.
> > 
> > I wasn't able to deduce any of this from the standard.  The standard
> > natters on about deallocating an allocatable function result as if it
> > actually is allocatable.
> 
> There is a local variable in the function that is the function result
> variable.  If that is declared allocatable, then that variable is what
> gets deallocated.  The result of the function is a value.  Values are
> not deallocated, as they can?t have the allocatable attribute.  I
> don?t think it is any more complicated that that.

9.7.3.2p4 disagrees with this analysis:

        If an executable construct references a function whose result is
        allocatable or has an allocatable subobject, and the function
        reference is executed, an allocatable result and any allocated
        allocatable subobject of the result is deallocated after
        execution of the innermost executable construct containing the
        reference.

> 
> Cheers,
> Bill
> 
> 
> > 
> >> Steve
> >> 
> >> _______________________________________________
> >> J3 mailing list
> >> J3 at mailman.j3-fortran.org
> >> http://mailman.j3-fortran.org/mailman/listinfo/j3
> > 
> > 
> > _______________________________________________
> > 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 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
> 
>