ISO/IEC JTC1/SC22/WG5 N1564 Response to N1533 (NEW_LINE) Michael Ingrassia Subgroup response to Dan Nagle's list of difficulties with NEW_LINE in paper N1533. >First, we don't acknowledge the possibility that the default character >type may not have control characters, let alone one which may be used >as newline, Subgroup: There should be no requirement that the default character set has control characters. [23:6] Delete '("newline", for example)' There might not be such a character. It is not a particularly illuminating example. >Second, we say where control characters are prohibited, but we don't >say how a program may obtain one (even in a note, even though we say >you need one to use all the features of formatted streams), and Subgroup: Correct. We ought not to say anything here. >Third, in fact, we don't say anything about control characters at all >(other than parenthetically remarking that newline is one), even how >they might affect the collating sequence (which might change an >existing program in an unexpected way), and Subgroup: No edits are needed. >Fourth, we allow processor to prohibit (some) control characters from >appearing in formatted streams! Evidently, we want to specifically allow >newline, Subgroup: Actually, we effectively disallow newline because it causes slash formatting action to occur instead of being written to the file as a normal character. >Fifth, we want to require that the C_NEW_LINE character be the same as >the character returned by NEW_LINE for the C_CHAR character type >(rather than noting that we anticipate a coincidence), Subgroup: No, we do not wish to require that. C_NEW_LINE must return the '\n' character for the particular companion processor. >Sixth, we ignore the effects of newline in formatted records (whether a >character expression written to a formatted stream can be written to a >formatted record), Subgroup: No edit required. It might indeed be possible for the requirements on record files and stream files to be different. >Seventh, while not required but since NEW_LINE is modeled after the >inquiry intrinsics, it would be nice to allow NEW_LINE to return its >value even when its argument is a nonpresent optional dummy argument of t>he procedure in which it appears (this allows a print procedure to >print an empty line or a default line when passed no string), and [127:41+] Add to the list (and renumber the rest) "(4+) The inquiry function NEW_LINE," >Eighth, again, while not required but since NEW_LINE is modeled after >the inquiry intrinsics, it would be nice to allow NEW_LINE in >initialization expressions (where many programmers will want to put >it), Subgroup: Agreed, but this is subsumed by the previous edit. >Lastly, we don't say how we want NEW_LINE to work with any default, >non-ASCII, non-ISO_10646 character types ('processor-dependent' isn't >much of a hint). Subgroup: Assuming newline exists for default characters, this is specified (e.g. See [235:1-7]). It should return a blank if no newline exists (edits following). [341:21] "," -> "and ASCII character 10 is representable in the default character set," [341:15] "." -> "or a blank if no newline is available" Subgroup: Finally, move a paragraph which is in the wrong place (this paragraph is not talking about "Other characters"). [24:15-20] Move to [23:20+]. [235:Note 10.17] Subgroup finds this note potentially confusing. Replace contents with "Record termination by a newline character can occur only on those processors that return a nonblank result from the NEW_LINE intrinsic function."