(j3.2006) associate name

[Kurt W Hirchert]

I think by Rafik's argument, (1) is already implied for any /selector 
/that is not scalar.  (If determining the attributes of an 
/associate-name/ requires evaluation of LBOUND  on the corresponding 
/selector/, then the /selector/ is implicitly constrained to be a valid 
argument for LBOUND.)

Unfortunately,  I don't see any way to extend this argument to scalars, 
and there seem to be problems there, too.  For example, if an 
/associate-name/ is associated with an unallocated allocatable scalar, 
what kind of dummy arguments, if any, can it be associated with in a 
procedure reference?  This looks to a can of worms you do not want to 
get into, so it may advisable to make (1) explicit.  I don't have a copy 
of the current standard handy. Is there an upwards compatibility issue?

-Kurt

On 4/28/2017 2:38 PM, Bill Long wrote:
> I see two alternatives:
>
> 1) In the description of the ASSOCIATE construct, say that assoc_name => x, where X is allocatable or a pointer requires that X is allocated/associated.  {Which seems reasonable anyway, since if X does not satisfy those conditions, then here is not much you can do with assoc_name.}
>
> 2) In the description of LBOUND (and UBOUND), change
>
> ARRAY shall be assumed-rank or an array. It shall not be an unallocated allocatable variable or a pointer that is not associated.
>
> to
>
> ARRAY shall be assumed-rank or an array. It shall not be an unallocated allocatable variable or a pointer that is not associated, or an associate name that is associated with an unallocated variable or a pointer that is not associated.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20170428/fdfc7187/attachment.html