# MOVE\_ALLOC extended to non-allocatable derived types containing allocatable components

**URL:** <https://fortran-lang.discourse.group/t/move-alloc-extended-to-non-allocatable-derived-types-containing-allocatable-components/10922>\
**Category:** Language enhancement\
**Created:** [May 22, 2026, 10:18am UTC](https://fortran-lang.discourse.group/t/move-alloc-extended-to-non-allocatable-derived-types-containing-allocatable-components/10922 "2026-05-22T10:18:14Z")\
**Posts on this page:** 3\
**Page:** 2

<div class="post-metadata">

**Author:** ![septc](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/septc/32/77_2.png) [@septc](https://fortran-lang.discourse.group/u/septc)\
**Post date:** [May 26, 2026, 2:37pm UTC](https://fortran-lang.discourse.group/t/move-alloc-extended-to-non-allocatable-derived-types-containing-allocatable-components/10922/21 "2026-05-26T14:37:44Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![everythingfunctional](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/everythingfunctional/32/176_2.png) [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)\
**Post date:** [May 27, 2026, 12:51pm UTC](https://fortran-lang.discourse.group/t/move-alloc-extended-to-non-allocatable-derived-types-containing-allocatable-components/10922/22 "2026-05-27T12:51:48Z")

</div>

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

```fortran
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

```fortran
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

```

---

<div class="post-metadata">

**Author:** ![TimBellerby](https://avatars.discourse-cdn.com/v4/letter/t/a88e57/32.png) [@TimBellerby](https://fortran-lang.discourse.group/u/TimBellerby)\
**Post date:** [May 27, 2026, 1:56pm UTC](https://fortran-lang.discourse.group/t/move-alloc-extended-to-non-allocatable-derived-types-containing-allocatable-components/10922/23 "2026-05-27T13:56:18Z")

</div>

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.

[Previous page](https://fortran-lang.discourse.group/t/move-alloc-extended-to-non-allocatable-derived-types-containing-allocatable-components/10922.md?page=1)