(j3.2006) (SC22WG5.5641) Is LOCK_TYPE still not locked up?
Thu Jan 21 16:10:55 EST 2016
In C1305 (C1303 in 10-007r1), a named variable with a declared type of
LOCK_TYPE (Corrigendum 4 introduces "declared") shall be a coarray, and
a named variable with a noncoarray subcomponent of type LOCK_TYPE shall
be a coarray.
188.8.131.52p4 says the <source-expr> in an ALLOCATE statement cannot have a
subcomponent whose dynamic type is LOCK_TYPE.
I hope we don't allow this, but I don't see where it's prohibited:
type :: T1
end type T1
type, extends(t1) :: T2
type(lock_type) :: L
end type T2
type :: T3
class(t1), allocatable :: Q
end type T3
type(t3), save :: V3[*]
type(t3), allocatable :: V4[*]
allocate ( type(t2) :: v3%q )
allocate ( v4, source=v3 )
The problem (if there is one) arises because the definition of
"subcomponent" stops at allocatable components.
The declaration of V3 doesn't fall afoul of C1305 because it doesn't
have a potential subobject component of type LOCK_TYPE.
I don't think the allocation of v3%q with type(t2) violates 184.108.40.206p4
because it's not a <source-expr>.
I don't think the allocation of v4 falls afoul of 220.127.116.11p4 because v3
doesn't have a subcomponent of whose dynamic type is LOCK_TYPE. V3 is,
however, of a type that has a potential subobject component of type
LOCK_TYPE. Does 18.104.22.168p4 need to say that instead of "subcomponent"?
If so, we still need to do more work on Corrigendum 4.
More information about the J3