************************************************** J3/03-111 Date: 12 February 2003 To: J3 From: Aleksandar Donev Subject: "Value Of" for Derived Types Reference: J3-007R3, continuing 02-330r1 ************************************************** ______________________________________________________ Summary ______________________________________________________ There is a gap in the draft as to what the typical words "something gets the value of something" really mean for objects of derived types allocatable and pointer components. I expect implementors to get confused and believe a clarification is needed. The way one copies the value of an object of derived type in reality is to do recursive ``bitwise'' copy for each component of intrinsic type, deep copy for allocatables, shallow for pointers. For polymorphic objects, this refers to the components of the dynamic type. Copying the value of something should never invoke a user-defined procedure in the current standard, and this should be kept so at this late date, though there are occasions, such as pass-by-value, where this may be useful. ______________________________________________________ Example ______________________________________________________ Where this matters most: TYPE, EXTENSIBLE :: base_type REAL, ALLOCATABLE, DIMENSION(:) :: A REAL, POINTER, DIMENSION(:) :: P END TYPE TYPE, EXTENDS(base_type) :: extended_type INTEGER, ALLOCATABLE :: S END TYPE TYPE(extended_type) :: object CLASS(base_type), POINTER :: polymorphic_object polymorphic_object=>object 1. VALUE dummy arguments of derived type with pointer/allocatable components (see 265:35-37). If object is passed as an actual for a VALUE dummy, typically a temporary copy is made which needs to allocate new storage with the same bounds if object%A is allocated and copy the values of A, and also copy the pointer association status of P. 2. Parenthesized expressions. If, for example, (object) is passed as an actual argument, the same as in 1 needs to occur. If instead polymorphic_object was used instead, the component S should also be copied by allocating new storage. ______________________________________________________ Solution/Edits ______________________________________________________ Others have suggested, and I try this below, that by simply making the definition of "set of values" for derived types in 4.5.6 (page 56) clear, the proper interpretation of how values are to be assigned or copied should follow. Please suggest alternatives if you do not find this clear! I personally think that for pointers we are in trouble. For regular pointers, "the value of" simply means the value of the target, because the pointer references its target. But for pointer components it should mean the pointer association status. This is the same problem with allocatables having different meaning inside and outside derived types as far as assignment goes, which we are trying to fix now. I find the whole system of definitions confusing and circular, but at this late date would not attempt to rehaul it completely. 56:27+ New text for 4.5.6: The set of values of a particular derived type consists of all possible sequences of component values consistent with the definition of that derived type and the type parameters. The component value for a nonallocatable nonpointer component is determined from the set of values for the type of the component. For pointer components, the component value consists of the pointer association status of the pointer component. For allocatable components, the component value is determined from the set of values for the type of the component and also includes the allocation status as well as the shape and array bounds in the case of allocatable array components. Questions: Do we need to say that the set of value of polymorphic objects is determined by the set of values of for the dynamic type? I do not see how to fit this in this standard. Do we need to ammend 31:15-16?