J3/99-226 Date: 1999/08/26 To: J3 From: /interop Subject: Responses to issues in 99-182r1 and N1356 All references are to 99-007r2, unless otherwise noted. Please note that the first issue appears in 99-182r1, but not in the revised paper 99-182r2. 1. In 99-182r1, the issue marked 7.5.1.5-6 in the right margin asks, "Would defined assignment ever be appropriate for the implied copy if a dummy argument has the VALUE attribute?" Response: Subgroup does not believe this would be appropriate. Argument association still applies to variables that have the VALUE attribute. Although the name of the attribute is meant to suggest that a copy of the value of the actual argument is made, permitting the copying to result in a reference to a defined assignment does not seem like a reasonable action, especially since that assignment can change the value that is being passed. In addition, such copying is not intended to be required by this facility - it's only suggestive of what is likely to happen in most implementations. Whether it does result in a copy is outside the scope of the standard. For example, module mod type, bind(c) :: dt integer :: i end type dt interface assignment(=) module procedure sub end interface contains subroutine sub(l, r) type(dt), intent(out) :: l type(dt), intent(in) :: r l%i = -r%i end subroutine sub end module mod program p use mod interface bind(c) subroutine sub(s) use mod type(dt), value :: s end subroutine sub end interface call sub(dt(17)) end program p In addition, the dummy argument that corresponds to the left-hand side of the defined assignment might have INTENT(INOUT). Presumably a processor would have no way of knowing how to create a temporary variable that was correctly "initialized" to meet any requirements of the procedure that defines the assignment. Finally, if argument association was intended, in Fortran, to have an effect similar to assignment, the language would likely permit the actual argument to be of any type that could be assigned to the dummy argument - at least in the presence of an explicit interface. 2. In N1356, WG5 suggests a way of addressing J3 issue 158. J3 thanks WG5 for the suggestion. However, the text of Note 12.38 [290:13-22] was not intended to place a requirement on a processor, so the word "shall" is not appropriate. Rather the following iterim edit will be applied: [290:33+] Append to issue 158 "Preliminary response: The use of the word may was intended to describe a possible state of affairs. The /interop subgroup will attempt to revise Note 12.38 using terminology from X/Open to describe a possible implementation choice."