(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