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

[Cohen Malcolm]

Yes this was all deliberate.

The result of a function with an allocatable result variable is not itself a 
variable and therefore not allocatable.  It's just a value.

> The
>description of move_alloc doesn't say FROM has to be a variable, but its
>intent is INOUT.

So yes the description of move_alloc DOES effectively say that it has to be 
a variable.

  "The INTENT (INOUT) attribute for a nonpointer dummy argument specifies 
that any actual argument that corresponds to the dummy argument shall be 
definable."

>  The OUT part of its INOUT has nothing to do with its
>value, only its allocation status (which becomes unallocated).

Only variables have allocation status.  Only variables and components can 
have the ALLOCATABLE attribute.  (We used to say this explicitly, but we 
seem to have dropped it for some reason; but anyway, there are no specified 
semantics for anything other than a variable or component to be 
allocatable.)

>We don't have any trouble saying that an allocatable function result is
>deallocated after it's used.

It's the function result *variable* that gets deallocated (after the value 
was used).

>  Why do we have a problem with FROM?

We don't.

>Did we intend to prohibit this?

Absolutely.

>If I do

Whether processors do or do not do some clever optimisations is not the 
purview of the standard.

Perhaps it would be better to be using an allocatable dummy argument if you 
want to do your own optimisations.

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