J3/99-201 Date: 09 August 1999 To: J3 From: Malcolm Cohen Subject: Interpretation request on PURE procedures NUMBER: TITLE: Defined assignment and INTENT(IN) dummy arguments in PURE procedures KEYWORDS: INTENT(IN), PURE, defined assignment, dummy arguments DEFECT TYPE: STATUS: QUESTION: Consider the following module: MODULE m TYPE t REAL,POINTER :: value END TYPE INTERFACE ASSIGNMENT(=) MODULE PROCEDURE t_asgn_t END INTERFACE CONTAINS PURE SUBROUTINE t_asgn_t(lhs,rhs) TYPE(t),INTENT(OUT) :: lhs TYPE(t),INTENT(IN) :: rhs ALLOCATE(lhs%value) lhs%value = rhs%value END SUBROUTINE PURE FUNCTION t_plus_t(a,b) TYPE(t) t_plus_t,a,b INTENT(IN) a,b t_plus_t = a !defined assignment !Alternative: CALL t_asgn_t(a,b) t_plus_t%value = t_plus_t%value + b%value END FUNCTION END According to F95 [212:33-45] "Constraint: In a pure subprogram any variable which ... is a dummy argument to a pure function ... shall not be used in the following contexts: ... (8) As the of an in which the is of a derived type if the derived type has a pointer component at any level of component selection; ..." Therefore it appears that the statement labelled "defined assignment" is not allowed. However, it is semantically equivalent to the commented-out statement in the following line, which would have been allowed. Clearly intrinsic assignment in that context must be disallowed as it implicitly does a pointer assignment which could be used to produce a side-effect, but the standard appears to rule out defined assignment as well (which if pure cannot cause any side-effect). Is this intentional? ANSWER: EDIT: SUBMITTED BY: Malcolm Cohen HISTORY: 99-ddd m150 submitted