J3/17-247 To: J3 Members From: Lorri Menard Subject: Comment 063; regarding EXTENDS_TYPE_OF and SAME_TYPE_AS Date: 2017 October 17 References: N2141, 17-007r2 1. Introduction: ~~~~~~~~~~~~~~~~~ [383:20] 16.9.76 [425:6] 16.9.165 The same discussion that led me to examine 10.2.1.3 also led me to look at the specifications of the intrinsic functions SAME_TYPE_AS and EXTENDS_TYPE_OF. The issues I see there are less definitive, but I include them here in case circumstances prove favorable for addressing them: 1. Taken by itself, the second sentence of NOTE 16.26 is vaguely mysterious. It is only by looking elsewhere in the standard that I conclude that this was intended to convey that if either argument to SAME_TYPE_AS is an unlimited polymorphic that is disassociated or unallocated, SAME_TYPE_AS should return false. I suggest that be made explicit, either in the specification or the note. 2. I am troubled by the aspects of these functions that are processor dependent. In the absence of any way for a program to know whether the results it receives are from a well-specified or process or defined case, there is no way to attach any meaning to those results. I suggest adding a note to both functions encouraging a policy for these cases of "when in doubt, return false". Such a policy would allow a program to attach meaning to true results. 3. I would prefer it if the results for intrinsic dynamic types were consistent with those for extensible derived types, rather than processor dependent. However, I recognize that "processor dependent" would allow processors to implement that way now and allow a future revision to impose that requirement, so I am not proposing any change in this regard unless changes here are deemed necessary for some other reason. 4. I am of the opinion that a serious error of omission took place with respect to these functions during the creation of F2003 and that this error has been propagated to subsequent revisions. These functions were precursors of the TYPE IS and CLASS IS type guards in the SELECT TYPE construct and were expected to produce equivalent results. When parameterized derived types were added to F2003, the type guards were modified to require kind type parameter value matching, but an equivalent change was not made in these two functions. Unfortunately, the result of this omission was not an incomplete or broken specification, just one sometimes giving the "wrong" answer. In the general case, there is nothing more that can be done with two objects known to be of the same type, but not necessarily the same kind type parameter values, than can be done with objects of different types. 2. Discussion ~~~~~~~~~~~~~~~~~ SAME_TYPE_AS and EXTENDS_TYPE_OF have limited functionality, and as such, do not apply in all circumstances. These constructs do not provided the same tests as TYPE IS and CLASS IS. The suggested edits are to add notes to these intrinsics to make this difference explicit. 3. Edits ~~~~~~~~~~~~~~~~~ Add a note [383:33+] Note 16.16+ Note that the test performed by EXTENDS_TYPE_OF is not the same as the test performed by the type guard CLASS IS. The test performed by EXTENDS_TYPE_OF does not consider type parameters. Add a note [425:17+] Note 16.26+ Note that the test performed by SAME_TYPE_AS is not the same as the test performed by the type guard TYPE IS. The test performed by SAME_TYPE_AS does not consider type parameters.