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

[Cohen Malcolm]

Lionel:
> >> 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.

Snyder:
> > I wasn't able to deduce any of this from the standard.

Obviously our intentions are not literally written into the standard; as 
Project Editor of the Allocatable TR that introduced this stuff, I was 
explaining our rationale for those who were not there at the time.

But it is pretty easy to deduce that we were trying for improved array 
functions over limited pointer functions by
(a) cannot return an unallocated result
(b) every element and every component of the result must be assigned a 
value.

Snyder:
> >  The standard
> > natters on about deallocating an allocatable function result as if it
> > actually is allocatable.

Yes, the result variable, for which we use the term "function result", is 
allocatable.  Literally, an allocatable function result *IS* the local 
variable in the function, not the value of the function reference.

Long:
> 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.

I agree:

Snyder:
>9.7.3.2p4 disagrees with this analysis:

No it does not.

>        If an executable construct references a function whose result is
>        allocatable

Right, "function whose result" is the "function result" in question, which 
is the local variable inside the function.  That is what the term "function 
result" means.

We use different wording for the value of the reference, e.g. for a function 
that returns a pointer "returns a pointer".  Note we did not write "returns 
an allocatable" here.

Snyder:
>This brings me back to the other question in my original message, which
>Malcolm erroneously interpreted as a question about the standard, rather
>than a question about what processors actually do:

No, I did not erroneously interpret it.  I just don't think it is a useful
question to ask of the committee that writes the Fortran standard.  We
designed the feature to facilitate a number of optimisations, but we cannot
force anyone to do them.

(And optimisations which rely on assignment being reallocating - which this
one does - are not going to happen when the compiler performs a different,
non-conforming, optimisation.)

The amount of effort being expended on this pointless argument is doubtless
greater than any amount of cpu time spent or saved by doing or not doing
some optimisation or other.

Snyder:
>If the result variable is in fact what gets deallocated, even though the
>word "variable" does not appear in 9.7.3.2p4,

And why should it?  This subclause is "Deallocation of allocatable 
variables", and only variables have an allocation status, so there is no 
ambiguity.

Not to mention that since our nomenclature change, we don't use "result 
variable" anywhere anymore anyway.  So it should not appear.

> then the result variable of F(X) in
>
>  call move_alloc ( f(x), v )
>
>IS a variable, right?  So what's the problem with executing it?

That is not standard-conforming because
(1) "f(x)" is not even a variable, let alone definable;
(2) "f(x)" does not have the ALLOCATABLE attribute.

As explained earlier, MOVE_ALLOC requires both arguments to be definable 
variables, by virtue of the INTENT specification.  So a conforming 
implementation can do anything it pleases; diagnosis of the error is 
optional, but doubtless we're having this discussion because the conforming 
implementations are in fact diagnosing that there is an error here.

Cheers,
-- 
.............Malcolm Cohen, NAG Oxford/Tokyo.