Inquire status of (non)allocatable arrays

[PierU]

@fpp

Do you think that the problem you’re referring to can be avoided if the proposed mechanisms were limited to arrays of the same rank?

No, the problem arises as soon as an array section is passed (e.g. a(:,5:7)). An array section can definitely not be considered as allocatable.

@fpp

Also, one might think of restricting the applicability of is_allocatable() and make_allocatable() to arrays that have been passed in full size (in your code snippet: call foo(a) instead of call foo(a(10,:)))

It could possibly work, but the problem is that the compiler wouldn’t know that a full array is needed in the call, and couldn’t detect the error if an array section was passed. And the execution would fail. A desirable behavior is to detect as many errors as possible at compile time as opposed to runtime.

There is actually another situation where even passing the whole array would not be enough to get what you want:

subroutine bar(n)
   real, intent(in) :: n

   real :: a(n)
   call foo(a)
end subroutine

subroutine foo(x)
   real, intent(inout) :: x(:)
   ...
   if (.not.is_allocatable(x)) make_allocatable(x)
   if (allocated(x)) deallocate(x)  !!! FAILURE
   allocate( x(5) )
   ...
end subroutine foo

a is here an automatic array, allocated at runtime upon entering the bar routine, and automatic arrays are often allocated on the stack. Reallocatating a stack variable is definitely not possible internally. It means that compilers should never allocate any array on the stack.

I have been frustrated also by the strong discrimation between allocatable and non allocatable arrays, typically when needing to return an array with a size that is not easily known in advance. One way is to have an allocatable dummy argument, but then it gets impossible to pass non-allocatable arrays. But I can not see good solutions to that.