Hi,

<snip>
>    "On completion of execution of the function, the value returned
>     is that of its function result. ... If the function result is
>     not a pointer, its value shall be defined by the function."

Now we can argue whether the "shall be defined" is to be interpreted as "has to
be" or as "might be". For me - being a non-native English speaker - that "shall"
is not an obligation but should be interpreted as "commonly the function result
is to be defined, but there can be exceptions". Now I am curious about how
native English speakers understand that standard statement.

My argument on returning an unallocated object is not to support programatical
errors, but rather for circumstances, where one tries to allocate a resource
and on failure nothing is returned. Think about a function like
try_to_acquire_resource(), when the resource could be reserved (like, for
example, a co-processor), then its (private) structure is returned
(implementing the OO concept of information hiding). Furthermore one could
think about using concepts like memory pools, where a memory fragment is
returned by a function as long as the capacity of the pool is no exhausted.
This of course is more difficult in Fortran as is lacks the ways of doing
C-style pointer arithmetic. This is just an example. So please don't nail me on
this one. I just wanted to give you my idea, why I think returning an
unallocated "object" should be legal for an allocatable function result. (Note,
the result is called allocatable, not allocated function result :-). Meaning,
that it can be allocated, but does not have to be.)

When someone has other compilers available the test program is attached.

Regards,
        Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Attachment: test_pr66775.f03
Description: Binary data

Reply via email to