[J3] [EXTERNAL] UTI 13 and 14

[Clune, Thomas L. (GSFC-6101)]

Hi Wililam,

Certainly notes are only informative, though you can safely assume that the committee’s intent was that such notes are implied from the constrants and rules.    The UTI’s are indicative of the fact that some corner cases were not properly addressed, and now is the time to do so.

UTI-013 points out that assumed KIND and LEN parameters are fundamentally unknowable for OPTIONAL arguments.    UTI-014 is a bit more esoteric and is concerned with inconsistent statements about what it would mean if we allowed CLASSOF() with unlimited entities.   As such, I think only UTI-013 is relevant to your concerns.

As new features, we have some latitude in defining just what should happen in corner cases.    Consider the following examples:

SUBROUTINE SUB1(S1, S2)
   CHARACTER(LEN=*), OPTIONAL, INTENT(OUT) :: S2
   TYPEOF(S1), INTENT(IN) :: S1
   …

END SUBROUTINE SUB1

SUBROUTINE SUB2(S1)
   CHARACTER(LEN=*), INTENT(IN) :: S1

   TYPEOF(S1), INTENT(IN) :: LOCAL
   …

END SUBROUTINE SUB2

If I have understood correctly, you would want TYPEOF in SUB1 to be equivalent to “CHARACTER(LEN=*)”.      But how would you want to interpret it is the SUB2 example.    We would either need to disallow data-ref’s that have assumed type parameters when declaring local variables,  or the semantics would need to be different for non-dummy declarations.    I believe the proposers' intent, and certainly mine, was that we would allow the SUB2 use case, and that it would work because the type parameters are not assumed for LOCAL but rathre established by the rules for S1.    But I did also not fully consider OPTIONAL at the time.

I think the wording C710 is intended to imply that the type parameters are not assumed.   I’m hardly the standardese expert,  but presumably the phrase “estabilshed by the implicit typing rules” is meant as opposed to being assumed.    Possibly that wording can/should be improved as part of dealing with this UTI.    (I defer to Malcolm on what the words need to be in order to tie this down.)

Give the choice of (a) allowing SUB1 but not SUB2,  (b) allowing SUB2 but not SUB1, or (c) a more complex wording that would allow both, which would be your preference?   I’m not strongly wed to any, but generally prefer option (b).

Cheers,

- Tom





On Oct 9, 2020, at 2:39 PM, William Clodius via J3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>> wrote:

As near as I can tell UTI-13 and 14 appear b because of the constraint mentioned in Note 2, "if the data-ref has an assumed type parameter, the entities declared have the same values for that type parameter as data-ref, they are not assumed (even if they are dummy arguments).” Now the explicit constraints on TYPEOF and CLASSOF are C709-712. My interpretation of those constraints is that they would allow the entities to have assumed parameters that need not be the same as data-ref. I find no other text outside the note and constraints affecting the interpretation of TYPEOF and CLASSOF. If I am right Note 2 is not just informative, but also has technical impact, which I thought was not allowed. Am I not interpreting C709-C712 correctly? Have I missed some additional text? Is a note allowed to have technical impact? Should there be an additional text outside the Note giving the interpretation currently specified by Note 2?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20201009/7a9ea760/attachment-0001.htm>