(j3.2006) comments on 17-007r2

Kurt W Hirchert kurthirchert
Mon Aug 14 15:03:54 EDT 2017


    The portion of paragraph 3 describing intrinsic assignment
    to an allocatable polymorphic variable does not address the
    possibility of a mismatched kind type parameter. 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, paragraph 3, sentence 2, after ?the
    dynamic type?, insert ?or any of the corresponding kind type
    parameter values?.


    The same discussion that lead me to examine 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
    addressing them:


        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.


        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
        true results.


        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...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20170814/0213ee81/attachment.html 

More information about the J3 mailing list