To:         J3 Members                                       J3/17-111
From:       Van Snyder
Subject:    Comments arising from Editor's report
References: 17-007 17-102
Date: 2017 February 01

Concerning 16-262r3, the editor suggested that "allocation status" ought
to be indexed, and that "association status" ought to be indexed as a
reference to "pointer association".  Here is a list of where "allocation
status" appears:

[46:19 5.4.10p1 Allocatable variables]
[87:20 7.5.8p1 Derived-type values]
[89:18 7.5.10p3 Construction of derived-type values]
[90:10 7.5.10p7 Construction of derived-type values]
[108:30+2 NOTE 8.14]
[111:20 8.5.15p1 SAVE attribute]
[113:2 8.5.19p1 VOLATILE attribute]
[142:2 9.7.1.1p2 Form of the ALLOCATE statement]
[142:4 9.7.1.1p3 Form of the ALLOCATE statement]
[143:22 9.7.1.3p1 Allocation of allocatable variables]
[143:36 9.7.1.3p3 Allocation of allocatable variables] (twice)
[144:5 9.7.1.3p5 Allocation of allocatable variables]
[144:7,9 9.7.1.3p6 Allocation of allocatable variables] (twice)
[145:4 9.7.3.1p2 Form of the DEALLOCATE statement]
[146:10+7 NOTE 9.23] (twice)
[146:24 9.7.4p1 STAT= specifier]
[147:11 9.7.4p3 STAT= specifier] (first list item)
[147:13 9.7.4p3 STAT= specifier] (second list item)
[147:19 9.7.5p1 ERRMSG= specifier]
[173:0+22 NOTE 10.43]
[195:13 11.1.7.5p4 Additional semantics for DO CONCURRENT constructs]
  (fifth list item)
[195:15 11.1.7.5p4 Additional semantics for DO CONCURRENT constructs]
  (sixth list item)
[212:6 11.6.5p2 SYNC MEMORY statement]
[287:10+2 NOTE 13.29]
[320:9 15.5.2.6p2 Allocatable dummy variables]
[323:43 15.5.2.13p1(2) Restrictions on entities associated with dummy
  arguments]
[347:0+4 Table 16.1] (second line)
[356:28 16.9.11p1 ALLOCATED (ARRAY) or ALLOCATED (SCALAR)]
[411:16 16.9.137p4 MOVE_ALLOC (FROM, TO [, STAT, ERRMSG])] (first list
  item)
[411:24 16.9.137p4 MOVE_ALLOC (FROM, TO [, STAT, ERRMSG])] (third list
  item)
[414:29 16.9.144p3 NULL ([MOLD])
[507:29 18.7p2 Restrictions on formal parameters]
[526:25 19.5.5p5 Establishing associations]
[531:6 19.6.6p1(11) Events that cause variables to become undefined]
[536:13,14 A.2p1 Processor Dependencies] (twice) (9.7.1.3)
[536:23 A.2p1 Processor Dependencies] (9.7.4)

Concerning 16-253r2, the editor remarked that using \ref to produce R5
instead of R2 in the note would cause it to be undesirably hyperlinked.
Is there a way to \ref without hyperlinking, or has the hyperref package
thoroughly subverted \ref?

Concerning 16-264r4, the editor changed NOTE 12.21 to normative text,
instead of moving it to be after the final paragraph of the subclause,
remarking that there did not appear to be normative text to support it.
This is already normative text in [17-007:229:27-28 12.5.6.2p1 General].
Reinstate the text as a NOTE (without "shall"):

[232:20 12.5.6.18p3 STATUS= specifier in the OPEN statement]
Delete "SCRATCH shall not be specified if the FILE= specifier appears."

[232:22+ 12.5.6.18p3+ STATUS= specifier in the OPEN statement].
"NOTE 12.21
  SCRATCH cannot be specified if the FILE= specifier appears."

The editor suggested that [16-007r2:39+1-2 NOTE 12.45] ought to be
reworded so as not to imply that a runtime prohibition could be checked
at compile time.

[17-007:249:16+2-3 NOTE 12.44] Replace the text:
"A data-transfer statement with an ID=, POS=, or REC= specifier cannot
be [executed as?] a child data-transfer statement in a
standard-conforming program."

Concerning 16-279r2, the editor rejected three edits that added
discussion of deferred type parameters to the list at the end of
subclause 19.5.5 Establishing associations, remarking that they "are not
right" and declined to repair them.  I can't think of a reason to
discuss (repeat) most of the events concerning essentially everything
else about an object, but omit deferred type parameters.  Here are the
rejected edits from 16-279r2, with revised line numbers:

[527:3 19.5.5p5(3) Establishing associations] after "(it is defined),"
insert "values of type parameters that are assumed,"

[527:8 19.5.5p5(4) Establishing associations] After "pre-existing
entity" insert ", the values of assumed type parameters if any become
the same as the values of corresponding type parameters of the
pre-existing entity,"

[527:9+ 19.5.5p5(4) Establishing associations] Insert a list item:

"  o  If an associating entity has an assumed type parameter its value
      becomes the same as that of the corresponding type parameter of
      the pre-existing entity."