(j3.2006) A horse that Aleks has been riding

[Van Snyder]

I recently needed to do

  rowSum = 0.0
  do i = 1, size(fCols)
    rowSum = rowSum + FwmJacobian%blocks(jRow,fCols(i))%values(chan,surf)
  end do

where jRow, chan, and surf are scalars, fCols is a rank-1 array, and
values has the POINTER attribute.

This would have been clearer as

  rowSum = sum(FwmJacobian%blocks(jRow,fCols)%values(chan,surf))

but C618 [10-007r1:119:16-17] says I can't do this.

I understand that the vector subscript has the potential to make things
discontiguous, and so does the POINTER (or ALLOCATABLE) attribute -- it
seems without any lesser or greater complication.  The POINTER attribute
can cause the same many-to-one problem that motivates 6.5.3.3.2p3, but
the ALLOCATABLE attribute cannot.

Is there really a reason any longer for C618?  Couldn't the restrictions
on vector subscripts in 6.5.3.3.2 [10-007r1:124:1ff] be applied instead
to the case of an array <part-ref> that has a subsequent <part-ref> with
the ALLOCATABLE or POINTER attribute?

While studying this, I wondered why the second and third items in the
list in 6.5.3.3.2p2 aren't constraints.  The second one is (C724
[10-007r1:158:19-20]), but the third one isn't.  Should it be?

I also wondered about the continuing need for the first one ("An array
section with a vector subscript shall not be argument associated with a
dummy argument that is defined or redefined").  We allow a discontiguous
actual argument to be associated with a contiguous dummy argument,
resulting (at least potentially) in copy-in/copy-out argument passing.
What's different about an array with a vector subscript (or an array
with a subsidiary <part-ref> with the POINTER or ALLOCATABLE attribute)?
What's really different about an array section with a vector subscript?
Shouldn't it be sufficient to add the essence of the first item to
6.5.3.3.2p3?