> On 9/3/12 7:09 PM, Ian Harvey wrote:
>> On 2012-09-04 9:46 AM, Dick Hendrickson wrote:
>>> On 9/3/12 5:50 PM, Ian Harvey wrote:
>>>> (bump, from a different nntp server because I'm seeing lots of orphaned
>>>> replies which make me suspect article propagation issues...)

>>>> If someone familiar with F2008 can have a look at this - I struggle to
>>>> believe that the standard would break the concept of PURE functions,
>>>> but
>>>> from my reading of the draft I think it has.

>>> I'm not sure, but I think the issue is that F2008 added VALUE as an
>>> attribute. This means that VALUE dummy arguments can be modified,
>>> because they have no external visibility. I think the other constraints
>>> still guarantee that non-VALUE things can't be modified. In fact, the
>>> NOTE still says they can't! It's takes more effort than I have to trace
>>> through all of the constraints. But, I think the list of 5 still makes
>>> it impossible for a PURE function to modify anything outside of the
>>> funtion.

>>> That's my guess.

>> Ok... I can see how VALUE has been accomodated with F2008, and that
>> specific aspect seems fine.

>> I wonder if those changes have inadvertently created the problem that I
>> see. The authors may have had the expectation that all dummy arguments
>> to a pure function were either INTENT(IN) or VALUE, but that's not
>> necessarily the case, so there are scenarios where that list of five
>> sub-points to C1283 simply don't apply - you don't trigger the
>> conditions in the lead-in paragraph of that constraint.

> I don't know the answer. I tried looking around in the PURE and argument
> association sections and didn't see anything obvious.

> I think the only dummy argument options are nonpointer data object,
> procedure dummy, and pointer dummy. I think the first two are easily
> covered by the 2008 rules. It's the pointer dummy that I don't see
> anything about. Maybe we need to appeal to Richard?

> I'll try to think a little more later in the day.

> Dick Hendrickson