To: J3                                                     J3/23-137
From: Steve Lionel & JoR
Subject: Disposition of JoR DIS Comments
Date: 2023-February-21

Reference: 23-112, N2009

US-023

Comment:
The requirements on the TARGET argument of
ASSOCIATED are wrong, leading to a contradiction in
the standard. The proposed change reword them to be
"how we intended" (i.e. retain backwards
compatibility, and do the obviously-right thing for new
cases). For data pointers that are not assumed-rank,
require the rank to be the same.

22-192r2, passed m228 provided the edits:

[27] 4.3.3 Fortran 2018 compatibility, p3+
(before the "different interpretation" paragraph)
Insert new paragraph
"Fortran 2018 permitted the POINTER and TARGET
arguments to the intrinsic function ASSOCIATED to have
different rank; this document does not permit such
usage."

Response:

The change is accepted.

US-024

Same as US-023 except for Fortran 2008 ([29] 4.3.4)

Response:

The change is accepted.

US-026

Same as US-023 except for Fortran 2003 ([29] 4.3.5)

Response:

The change is accepted.

US-041

Same as US-023, but actual edits [[361] 16.9.20 ASSOCIATED)

Suggested edit:
Arguments paragraph, TARGET argument,
replace entire description with that below.

Note: the second sentence of the first paragraph is unchanged.

"shall be a pointer or an entity that could be a target. If TARGET is a
pointer then its pointer association status shall not be undefined.

If POINTER is a procedure pointer, TARGET shall be a procedure (or
procedure pointer) that would be allowable as the target of a pointer
assignment (10.2.2) for a procedure pointer with the same
characteristics as POINTER.

Otherwise, TARGET shall be a noncoindexed variable that is not an
array section with a vector subscript, or a reference to a function
that returns a data pointer. If POINTER is not unlimited polymorphic,
TARGET shall be type compatible with it, and the corresponding kind
type parameters shall be equal. If POINTER is not assumed-rank, TARGET
shall have the same rank as POINTER."


Response:

The change is accepted.

GB-042

Comment: (16.9.210p2 TOKENIZE)
This says the tokens are assigned "by intrinsic
assignment", but the standard usually says "as if
by intrinsic assignment" when there is no actual
assignment statement.

Suggested edit:
Change the para to:
"The tokens in STRING are assigned in the order
found, as if by intrinsic assignment, to the elements
of TOKENS, in array element order".

Response:

The change is accepted.

US-043

Comment: (16.9.210 TOKENIZE)

As passed in PL22.3 paper 22-193 (m228), in the last line of the
paragraph describing the FIRST argument, replace "delimitor" with
"delimiter".

Response:

The change is accepted.

**-053

Comment: (Introduction)

"When a deferred-length allocatable actual
argument of an intrinsic procedure is to be
assigned character data,"
In ISO deliverable, is to be/are to be = shall,
which is not allowed in the introduction.

Suggested edit:

Remove "to be".

Response:

The change is accepted.

GB-054

Comment: (Introduction)

The sentence 'A deferred-length allocatable io-unit
in a WRITE statement is allocated by the
processor to the length of the record to be written.'
is true only if the variable is scalar (see 12.4, bullet 4.)

Suggested edit:

Change "A deferred-length allocatable io-unit in a WRITE
statement" to "'A deferred-length allocatable scalar io-unit
in a WRITE statement".

Response:

The change is accepted.

--END--