Several of my compiler reject it, though not all.
Non-comprehensive example:
integer, target :: c = 55
integer, pointer :: a, b
a() = c ! << Statement function with pointer attribute
allocate(b)
b = a() ! (1)
b => a() ! (2)
end
Tobias
Hmm. It certainly is not intended to be allowed. I'm completely sure of
that. Statement functions were deliberately not extended at the same
time as they were made obsolescent. I'm not seeing the explicit
prohibition at the moment, though I might well just be overlooking it.
I do see what I'd say amount to implicit prohibitions, though in that
there is no interpretation of what such a statement function would do.
For the pointer case, I see no way that the statement function could
return a pointer result, which seems to me an implicit prohibition. An
explicit one would be better, but an implicit one seems adequate to
establish intent.
The definition of statement functions does say that the value of the
statement function is computed by evaluating the expression. The value
of the expression in your example is the integer 55, not "a pointer to
C". I see nothing anywhere that allows an interpretation of the above as
returning a pointer to C.
For allocatables, I see a requirement that the statement function be
scalar. There is no way to explicitly allocate it and the requirement
for being scalar is going to hit most ways of implicit allocation.
Perhaps a scalar character string with allocatable length? I can't
off-hand see any other possibility. Oh, I see that implicit allocation
is more generally out because there is no intrinsic assignment statement
around. Just because a statement function looks a lot like an assignment
statement definitely does not mean they are the same thing. The
statement function reference might appear in an assignment statement,
but that would not do anything to allocate the statement function
result.
Those are all arguments about implicit prohibitions. I agree that an
explicit one would be better, but I think you have your answer as to
whether it is standard conforming, even if not a good answer as to where
simple words to cite might be.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
I can see it, but I think that is is mistakenly phrased. If the
phrase "other than a statement function" were removed from 12.3.1.1,
the requirement in 12.3.1 that all statement functions have implicit
interfaces would eliminate it.
Regards,
Nick Maclaren.