(j3.2006) Allowed but not desired?

[Van Snyder]

On Wed, 2014-10-08 at 10:45 +0900, Malcolm Cohen wrote:
> 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,

"C1303" was a typo.  Should have been C1302.  C1302 says a lock variable
shall be a coarray.  No coarray in sight in the declaration of A.

> >>>
> 
> 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,