MOVE_ALLOC extended to non-allocatable derived types containing allocatable components

Language enhancement
21

Yes, I guess it may be possible to write the desired routine if flexible reflection capability (in future fortran) becomes available, but even in that case I guess library codes may be far from straightforward to write (because of iterative/recursive component scan, as suggested), as compared to just using an intrinsic “move” statement (like a <- b or some routine to distinguish from value assignment).

22

Maybe I’m missing something, but why is the following not sufficient?

type(T), allocatable :: A, B
allocate(A)
...
call move_alloc(from=A, to=B)
...

Or is it that you really don’t want the allocatable attribute on your variables? Or is it that you only want certain components moved over? If that’s the case, the compiler doesn’t know which ones you want moved/pointed/copied vs which ones you don’t. Presumably that will have more to do with your domain and design than which attribute you happened to use. Or am I still missing something?

For example

type :: T
  integer, allocatable :: A(:) ! move this one
  real, allocatable :: B(:) ! not this one
  integer, pointer :: P(:) => null() ! not this one
  real, pointer :: Q(:) => null() ! point to this one
  integer :: X ! copy this one
  real :: Y ! not this one
end type

subroutine move(from, to)
  type(T), intent(inout) :: from
  type(T), intent(out) :: to

  call move_alloc(from=from%A, to=to%A)
  to%Q => from%Q
  to%X = from%X
  call undefine(from)
end subroutine

subroutine undefine(A)
  type(T), intent(out) :: A
end subroutine
23

For individual variables, sure there is no real advantage. However, for array elements you may have good reason not to wish to individually allocate each element but still find a copy-but-move-allocatable-components operation useful. After such as operation, the source would have all of its components deallocated, reverting to an essentially uninitialised (but safe) state which could then be re-initialised by assignment. This behaviour could be particularly useful when writing generic routines that wished to avoid expensive copies of potentially large allocatable components (e.g.: implementing expandable arrays as per a previous reply in this thread, re-arranging array elements in place, destructive repacking, etc.). Yes, this is less general that being able to choose which elements to move over, but I do think it could still be useful.