Query about function result having allocatable component of derived type

[Richard E Maine]

On Sep 20, 2006, at 12:00 AM, Sudesh Chandna, Noida wrote:

> For allocatable function result standard says that "Function result
> should be allocated and have defined value on return".

I'm not sure where you found this quote. I can't off-hand find  
anything like it in the standard. A page and line number, or section  
and paragraph would help. Of course, I am looking in the f2003  
standard because allocatable function results are not in f95 except  
with the TR. It is possible that words somewhat like that are in the  
TR, although the TR words are supposed to have been largely copied  
into f2003. I'm almost certain that this is not an exact quote from  
either the standard or the TR, because the usage of the word "should"  
is completely wrong for standard-speak and I would not have expected  
the committee to overlook something quite that basic and important.  
The word "should" means a non-mandatory recommendation in a standard.  
Hmm. Let me check the TR. Ok, I found words that are at least similar  
to this in the TR.  They are in the explanatory material rather than  
in the TR's edits to the standard, and they aren't exactly these  
words (for example, they don't include the word "should"), but they  
are close. Ok.

> Now my question is Does above rule applies to function result of  
> derived
> type having allocatable component.

Having an allocatable component does not make an entity itself  
allocatable. So if those are indeed the words of the standard, then  
they would not apply. However...

As I noted above, this is just in the explanatory material of the TR  
- not in the TR's edits to the standard. That's because this "rule"  
isn't a rule, but is just an explanation of the consequence of other  
rules. This is basically redundant with the general rule that (from  
f2003, but f95/f90/f77 all say pretty much the same kind of thing)

   "If the result variable is not a pointer, its value shall be  
defined by the function."

An unallocated allocatable does not have a defined value. That's what  
allows one to deduce the above "rule".

Likewise, a derived type entity is defined if and only if all of its  
components are defined. Therefore, if it has an allocatable component  
and that component is undefined, then the derived-type entity is  
undefined. That would imply that the allocatable components of a  
function result are required to be defined.

However... I'm guessing that the requirement for a function result to  
be defined is a poorly stated holdover from days before defined  
assignments/operators. That requirement made sense in f77 because  
function references were always used in contexts that required the  
result to be defined. As such, the requirement was almost redundant,  
but not quite, in that it allowed a processor to diagnose some simple  
cases (such as not having anything in the function that could define  
the variable) at compile time, rather than waiting to be sure that  
the function was actually invoked. Without this condition, one could  
have argued that such a function was valid as long as it was never  
invoked (there do exist other things that silly in the standard - not  
directly intentionally, but as consequences of other things).

With defined assignment and defined operators, it is possible to use  
a function result in a way that would be ok if it were not defined.  
That is even technically possible for intrinsic types, but is arcane  
there. For derived types, it is quite plausible that a defined  
assignment subroutine or a defined operator function might not  
reference all the components. This matter was discussed and generated  
a correction in the standard at one place, as I recall.

I am suspicious that the same thing applies here - that a literal  
reading of the standard says that the component must be allocated,  
but that this is an error in the standard. I would expect that it  
would depend on how the function result was used. If the result was  
used in a way that required the component to be allocated, then it  
has to be allocated; otherwise, it doesn't. But that's just my guess  
as to how it ought to be. I can't say for sure that J3/WG5 would  
agree. I'll send an email to the J3 list asking. At the moment, I  
have to say that the literal words of the standard do imply that a  
component has to be allocated.

> So should compiler generate error for this as well.

Note that in any case, this is not a condition that the standard  
requires to be diagnosed. It is comparable to referencing undefined  
variables (very comparable). My personal recommendation would be to  
not directly diagnose it as an error just because a function returned  
something like this. Even if the interpretation that it is illegal  
holds, you could consider it a minor extension. However, if you are  
doing diagnosis of things like references to undefined variables, you  
might end up diagnosing it where it is used invalidly. That would  
probably end up being most uses, but it would not be a separate check  
- just one of many ways that one could run into the condition of  
having an unallocated component in a "bad" context.

On the other hand, since most uses would be invalid, one might argue  
for not making such an extension.

-- 
Richard Maine                |  Good judgment comes from experience;
Richard.Maine@nasa.gov       |  experience comes from bad judgment.
                             |        -- Mark Twain