(j3.2006) Need an interp for this?

[Van Snyder]

Malcolm Cohen wrote:
> No interp is required.
>
>   
>> module testr_m
>>  type :: ty
>>    integer, allocatable  :: l2p(:)
>>  end type ty
>> contains
>>  subroutine testr(d)
>>    type (ty), intent(inout) :: d ! Provides various options,
>>    associate(l2p=>d%l2p)
>>      allocate (d%l2p(4), stat=i)
>>     
> ...
>   
>> the "allocate" statement ought to be disallowed.
>>     
>
> Not so.  It defines the variable I with a processor-dependent positive value.
>   

Change allocate to deallocate, and assume d%l2p is allocated.  Then what 
happens to the associate name?

>> There's nothing in 8.1.3 to prohibit it.
>>     
>
> Standard says an allocatable object has to be unallocated here.
>
>   
>> There's also nothing that says d%l2p has to be allocated when the
>> "associate" statement is executed.
>>     
>
> See 16.5.1.6 Construct association.
>
>   
>> We consciously modeled the associate construct on argument association,
>> but we have apparently left out several of the important restrictions on
>> arguments.
>>     
>
> Apparently not.  Some of the more obscure ones might be harder to extract 
> though.
>   

I had in mind primarily the requirement that actions that affect the 
dummy argument be taken through the dummy argument.  Allocating or 
deallocating d%l2p affects the associate name l2p.  We don't allow a 
procedure to allocate or deallocate an actual argument, accessed for 
example by host association, and ought not to allow it for a selector.

> Cheers,
>