[J3] surprisingly PURE

[Steve Lionel]

I admit that I am not all that good as a language lawyer, but I think 
Steve K has it right.

C1594 says (with irrelevant parts removed):

In a pure subprogram any designator with a base object that is in common 
or accessed by host or use association,...  or an object that is storage 
associated with any such variable, shall not be used
  (1) in a variable definition context (19.6.7),

My reading here is that Y%P is an object that is storage associated with 
X, which is accessed by host association, and therefore Y%P shall not be 
used in a variable definition context.

I welcome other viewpoints.

Steve L


On 4/18/2020 9:31 PM, Robert Corbett via J3 wrote:
> I assume you mean C1594 (1).
>
> No part of C1594 applies to
> this example.  The variable Y is
> a local variable of SUBR.  The
> variable Y does not satisfy any
> of the conditions listed at the
> start of C1594.
>
> Robert Corbett
>
>> On Apr 18, 2020, at 4:38 PM, Steven G. Kargl <kargl at troutmask.apl.washington.edu> wrote:
>>
>>> On Sat, Apr 18, 2020 at 11:12:27PM +0000, Robert Corbett via J3 wrote:
>>>        REAL, TARGET :: X = 1.0
>>>        TYPE T
>>>          REAL, POINTER :: P => X
>>>        END TYPE T
>>>        CALL SUBR
>>>        PRINT *, X
>>>        CONTAINS
>>>          PURE SUBROUTINE SUBR
>>>            TYPE(T) Y
>>>            Y%P = 2.0
>>>          END SUBROUTINE SUBR
>>>        END
>>> -------------------------------
>>>
>>> I think the program given above is standard conformant.
>>> If it is not standard conformant, please let me know
>>> why it is not.  I know that it should not be standard
>>> conformant, but I see no reason it is not.
>>>
>>> The key point here is that default component
>>> initialization does not give the variable the SAVE
>>> attribute.  If Y had the SAVE attribute, the program
>>> would not be conformant.
>>>
>>> This program is my third attempt to show this problem.
>>> My first program was not conformant, and my second did
>>> not properly demonstrate the problem.
>>>
>> Doesn't f2018:C1593(1) apply?  I admit I have troubling reading
>> this section of the Fortran standard.
>>
>> -- 
>> Steve