(j3.2006) Allowed but not desired?

[Malcolm Cohen]

Van Snyder writes:

<<<
This appears to be allowed, but I think it's not what we want:
>>>

Actually I think it is not allowed to be used, and I think it is harmless 
anyway.

<<<
module M

  type :: T1
    type(lock_type) :: L
  end type T1

  type :: T2
    type(t1), allocatable :: C
  end type T2

...

contains

  subroutine S ( A )
    type(t2), intent(out) :: A
...

This appears to be wrong, on two counts.

First, the intent of C1303 is probably that A%C%L ought to be a coarray,
>>>

Well, I fundamentally disagree that that restriction is necessary or desirable. 
It is a coding guideline and not a particularly good one.

<<<
Second, A has intent(out).  The intent of C547 is that A%C%L not become
undefined due to deallocation of A%C because A is intent(out).
But A%C%L is not a subcomponent of A, because A%C is allocatable.
Therefore, C547 does not apply.

Is this what we wanted?
>>>

(1) Yes the definition of the procedure is allowed.  But it cannot be called 
(see 3).

(2) The procedure is perfectly harmless because the lock variable is 
allocatable.  Allocating/deallocating a lock variable needs to be known to the 
compiler (as it might require special OS action to set it up), but it is known 
so no problem.  We allow deallocation of lock variables, even many of them at 
once, so no problem there.  Allocating/deallocating a lock variable is not any 
kind of synchronisation (unless it is for some other reason e.g. the lock 
variable being an actual coarray in itself), so no problem there.

The only problem with INTENT(OUT) comes for nonallocatable lock variables (which 
we absolutely do not want to just become "undefined").  Which C547 prohibits. 
So we seem to be fine on the procedure definition front.

(3) It is impossible to call subroutine S because any actual argument will 
violate C1304.  It looks like we could modify C1304 to prohibit just the 
problematic cases by inserting "nonallocatable" before "subobject".  But given 
the current state and complexity of the whole LOCK_TYPE situation I don't have a 
lot of enthusiasm for that right now.  Perhaps sometimes later when we have the 
situation straightened out enough to be both understandable and obviously 
correct (though that sounds a bit overoptimistic!).

Chers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.