(j3.2006) Comment 1 from TS Ballot

[Bader, Reinhold]

Hello Bill, 

ad 1) Yes.

ad 2) I don't think so

ad 3) I think relying on [96:15] in Fortran 2008 stretches things a bit. My understanding of that sentence could be paraphrased by "Don't use a descriptorless entity in places that require creation of a descriptor", and with assumed-rank we've created an exceptional situation where I think said sentence probably should be modified to 
"Unless for argument association with an assumed-rank dummy argument, an assumed-size array shall not appear in a context that requires its shape."
(an additional edit in section 9 of the TS) in order to more unambiguously state that this special situation is permissible. 

I certainly also think that plugging this hole is more an exercise in consistency (and serves to assure implementors that a situation they cannot handle cannot occur) than of any practical importance (since it is not possible to construct an interoperable entity via a designator from a non-interoperable one anyway, C535b of the TS). So if people feel that 
[96:15] in Fortran 2008 cannot be misinterpreted to also disallow your example if you remove INTENT(OUT) from the declaration of arank in sub2, I'm game.

Regards
Reinhold


> -----Urspr?ngliche Nachricht-----
> Von: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-
> fortran.org] Im Auftrag von Bill Long
> Gesendet: Donnerstag, 6. September 2012 18:04
> An: fortran standards email list for J3
> Betreff: (j3.2006) Comment 1 from TS Ballot
> 
> Hi All,
> 
> I tried sending this to the interop-tr email list but got an error
> message back from the server.  So I'm resending to the j3 list.  Sorry
> for duplicates if the original one worked.
> 
> =========
> 
> Hi All,
> 
> We need to create a response document for the comments made in the votes
> on the ISO TS ballot.  This email starts the discussion on the first
> comment.
> 
> 
> The ISO ballot on the DTS for TS 29133 (Interoperability TS) resulted
> in a total of two comments, both technical and from Germany.
> 
> The following starts the discussion of the first comment. Please,
> especially Reinhold, post to the list if you think I have misunderstood
> the intent of the comment.
> 
> 
> -------From the Ballot Response for Comment 1-----------------
> 
> Technical comment 1 from Germany:
> 
> For an assumed-rank INTENT(OUT) dummy variable argument associated
> with an assumed size actual argument (possibly across more than one
> invocation level), the number of array elements to perform
> finalization or deallocation of allocatable type components on is not
> available. Note that in BIND(C) interfaces the above situation cannot
> occur due to C1255b and C407a, but an assumed-rank entity may appear
> in an interface that is not interoperable.
> 
> Preferred proposed change:
> 
> In 5.2p3, after C535b, add a new paragraph: "For a non-allocatable
> non-pointer assumed-rank object that has the INTENT(OUT) attribute,
> the SIZE intrinsic (6.4.2) shall return a non-negative value."
> 
> -------End of Ballot Response for Comment 1-------------------
> 
> 
> The problem raised in the comment is illustrated by the following example:
> 
> module modu
> 
>     type c1_t
>        real,allocatable :: x(:)
>     end type
> 
> contains
> 
>     subroutine sub1 (asize)
>     type(c1_t) :: asize(*)
>     call sub2 (asize)   ! allowed??
>     end subroutine sub1
> 
>     subroutine sub2(arank)
>     type(c1_t),INTENT(OUT) :: arank(..)
>     end subroutine sub2
> 
> end module modu
> 
> program test
>    use modu
>    type(c1_t) :: eshape(10)
> 
>    do i=1,10
>       allocate(eshape(i)%x(100))
>    end do
> 
>    call sub1 (eshape)
>    print *, allocated(eshape(1)%x)  ! Expect F
> 
> end program
> 
> The issue arises because the call to sub2 results in the components of
> its argument being deallocated because of the INTENT(OUT) attribute on
> the dummy argument arank.  The proposed added paragraph would prohibit
> an assumed-size actual argument being associated with an assumed-rank,
> intent(out) dummy argument like the one in sub2.  The ultimate problem
> is that the processor needs to know the size of the argument in order
> to deallocate the correct number of component arrays.
> 
> Note that if sub2 was a BIND(C) subroutine the code would already be
> disallowed because the argument type is not interoperable.
> 
> 
> Proposed response for this example:
> 
> This case is already covered by the general
> prohibition at [96:15] in Fortran 2008, which is not modified by the
> TS, and states "An assumed-size array shall not appear in a context
> that requires its shape.".  The appearance of asize in the call to sub2
> violates this rule.  The proposed new text is effectively a restatement of
> this rule for a particular case, and hence is unnecessary.
> 
> Comments, please...
> 
> 1) Does the example accurately represent the intent of the comment?
> 
> 2) Are there other cases included in the Ballot Comment that are not
> covered by the response?
> 
> 3) Is the response correct?
> 
> ...
> 
> 
> Cheers,
> Bill
> 
> 
> 
> 
> --
> Bill Long                                           longb at cray.com
> Fortran Technical Support    &                 voice: 651-605-9024
> Bioinformatics Software Development            fax:   651-605-9142
> Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3