set_allocate as a safe wrapper around ALLOCATE

[Beliavsky]

I don't like to use allocation on assignment, because it is too inconspicuous, and for me, error-prone. I prefer it to be "glance clear" when I am allocating memory. A problem with using ALLOCATE, however, is that you must check if the variable is already ALLOCATEd. Should stdlib have a subroutine set_allocate that is safe to use for already ALLOCATEd variables? Below is an example for a 1D integer array. In my own codes I have overloaded set_allocate to handle 1D, 2D, and 3D arrays of the basic types, and I use set_allocate extensively. Using fypp, I think code for set_allocate could be generated for all types and ranks up to say 7. You could write set_allocate to have two optional arguments, source and mold, that would have to be the same shape if both present.

module m
implicit none
private
public :: set_allocate
contains
subroutine set_allocate(out,source)
! allocate out and set it to source
integer, intent(in)               :: source(:)
integer, intent(out), allocatable :: out(:)
allocate (out,source=source) ! intent(out) argument already deallocated
end subroutine set_allocate
end module m

program main
use m, only: set_allocate
implicit none
integer, allocatable :: ivec(:)
allocate (ivec(3))
! allocate (ivec,source=[5,2]) ! not legal since ivec already allocated
call set_allocate(ivec,source=[5,2]) ! legal
print*,"ivec=",ivec
end program main

[milancurcic]

I do something similar in Chapter 5 of my book (I called the subroutines alloc and free):

subroutine alloc(a, n)
  real, allocatable, intent(in out) :: a(:)
  integer, intent(in) :: n
  integer :: stat
  character(len=100) :: errmsg
  if (allocated(a)) call free(a)
  allocate(a(n), stat=stat, errmsg=errmsg)
  if (stat > 0) error stop errmsg
end subroutine alloc

subroutine free(a)
  real, allocatable, intent(in out) :: a(:)
  integer :: stat
  character(len=100) :: errmsg
  if (.not. allocated(a)) return
  deallocate(a, stat=stat, errmsg=errmsg)
  if (stat > 0) error stop errmsg
end subroutine free

@certik didn't like this style, but if there's enough demand for something like that from people, I'd support it.

[certik]

Yes, I recommend to use Fortran features directly, not to write wrappers.

But if there is demand, we can always have such routines in stdlib, I don't think it hurts to have options. In some sense it is similar to our wrappers around open:

stdlib/src/stdlib_io.fypp

Line 182 in 8228b94

integer function open(filename, mode, iostat) result(u)

One issue with the above alloc / free is that it still does not fix the main issue that people might have with allocate, and that is when using in libraries, we do not want to "panic" (with error stop), but rather return the error to the caller. That requires error propagation which requires to refactor pretty much every routine that calls it. For a lot of numerical codes and applications that I've seen in use, it seems ok to fail ("panic") like that (simpler code and the error never gets silenced by some routine forgetting to check the status), but I have also seen codes where this is not ok.