To: J3 J3/21-113 From: Malcolm Cohen Subject: Interpretation of CLASS(*) overloading Date: 2021-February-21 ---------------------------------------------------------------------- NUMBER: F18/023 TITLE: CLASS(*) ambiguous operator overloading KEYWORDS: CLASS(*) generic OPERATOR DEFECT TYPE: Erratum STATUS: J3 consideraton in progress QUESTION: Consider the program Module m Interface Operator(==) Module Procedure mp End Interface Contains Logical Function mp(a,b) Class(*),Intent(In) :: a,b mp = .False. Select Type(a) Type Is (Integer) Select Type(b) Type Is (Integer) mp = .True. End Select End Select End Function End Module Program ambiguous Use m If (13==999) Then Print *,'Invoked the user function' Else Print *,'Did not invoke the user function' End If End Program Is this program valid? If so, does it invoke the user function or the intrinsic operation? It is clear from the standard that the user is not supposed to be able to override intrinsic operators, merely extend them. The last sentence of 15.4.3.4.2p1 "Defined operations" says: "If the operator is an intrinsic-operator (R608), the number of dummy arguments shall be consistent with the intrinsic uses of that operator, and the types, kind type parameters, or ranks of the dummy arguments shall differ from those required for the intrinsic operation (10.1.5)." However, CLASS(*) encompasses these while "differing". ANSWER: The program is not conforming because it is ambiguous. However, the interface was intended to be forbidden; as noted, the standard clearly intended to prohibit overriding intrinsic operations. An edit is provided to correct this oversight. EDITS to 18-007r1: [295:11] 15.4.3.4.2 Defined operations, p1, last sentence, After "(10.1.5)" insert ", treating a CLASS(*) dummy argument as not differing in type or kind". {A bit ugly, but we can't use "distinguishable" because operations have operands not arguments." SUBMITTED BY: Paul Richard Thomas HISTORY: 21-nnn m223 Submitted ----------------------------------------------------------------------