(j3.2006) Vipul Parekh's post in comp-fortran-90

Van Snyder Van.Snyder
Wed May 31 16:48:33 EDT 2017

This is a revision of a previous message, that had the defect that the
variable foo was not given the allocatable attribute.

Vipul Parekh posted a question in comp-fortran-90 that makes me believe
we need an interp concerning recursive relationships between types using
allocatable components.  His example was

  type :: t
    type(t), allocatable :: next
  end type t
  type(t), allocatable :: foo
  foo = t(foo)
  print *, 'Is foo%next allocated? ', allocated(foo%next)

For this example, I'd say the print statement ought to print F

But in this example

  allocate ( foo )
  foo = t(foo)

it appears that there is a cyclic relationship between foo and itself
using its next component.  It depends upon whether foo is deallocated
before t(foo) is evaluated.  If it's not, there is a cyclic
relationship.  I believe one of the goals of the initial design of the
ALLOCATABLE attribute was to prevent cyclic relationships.

New stuff:

        Tom Clune has pointed out that during the assignment the next
        component is deep-copied from the constructor to foo, so maybe
        there's no problem.

It might be necessary to add to the requirements for assignment to an
allocatable variable that it is deallocated if it has any allocatable
components.  This might be too strong.  For example, it would prevent
walking down a linked list using

  foo = t(foo%next)

A possibility for this example is to interpret it as

  type(t) :: temp
  allocate ( foo )
  call move_allocate ( foo, temp )
  foo = t(temp)

But it's not obvious that scenarios using multiple recursively-connected
types don't still result in cyclic relationships.

This will need some deep investigation.

Althogh I'm the one who proposed to allow recursive relationships
between types using allocatable components, maybe we ought to remove it.

More information about the J3 mailing list