(j3.2006) comments on 17-007r2
Kurt W Hirchert
Mon Aug 14 15:03:54 EDT 2017
The portion of 10.2.1.3 paragraph 3 describing intrinsic assignment
to an allocatable polymorphic variable does not address the
possibility of a mismatched kind type parameter. 10.2.1.2 paragraph
1 item (7) precludes such a mismatch in any kind type parameter that
is part of the declared type of the variable, but if the dynamic
type is different, there exists the possibility of kind type
parameters added in the extension. It does not appear that this
failure to address was intentional: Such kind type parameter
mismatches are definitely not allowed in the nonpolymorphic case.
Although a plausible interpretation can be made for how to handle
the mismatch in the most common cases, the cost of implementing that
interpretation is significant. For many of the less common cases, no
such plausible interpretation appears to exist.
_Suggested edit_: In 10.2.1.3, paragraph 3, sentence 2, after ?the
dynamic type?, insert ?or any of the corresponding kind type
The same discussion that lead me to examine 10.2.1.3 also lead 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
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
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 processor-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
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.
I am of the opinion that a serious error of omission tokk 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.
The question facing the committee, then, is what to do with two
functions well specified to return values of no use. My
preference would be to ?fix? the specifications to require
matching corresponding type parameter values for a true result.
Alternatively, the functions could be marked now as obsolescent,
since no replacement should be necessary for features which have
no useful functionality. Simply ignoring the problem does not
strike me as a reasonable response.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the J3