To: J3 J3/20-152r2 From: Robert Corbett & Malcolm Cohen Subject: Optional comma in type declaration References: 18-007r1 Date: 2020-October-14 ---------------------------------------------------------------------- NUMBER: F18/021 TITLE: Optional comma in type declaration DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: The program PROGRAM EXAMPLE1 CHARACTER*1, C(SUM([0, 1])) END is a conformant Fortran 2018 program. The program PROGRAM EXAMPLE2 CHARACTER*1 C(SUM([INTEGER:: 0, 1])) END is also conformant. The similar program PROGRAM EXAMPLE3 CHARACTER*1, C(SUM([INTEGER :: 0, 1])) END violates constraint C725 of 18-007r1. The constraint states C725 (R722) The optional comma in a \si{length-selector} is permitted only if no double colon separator appears in the \si{type-declaration statement}. Q: Should the optional comma be permitted when the \si{type-decalaration-statement} includes a double colon separator in an expression? ANSWER: A: Yes. The Fortran 90 and Fortran 95 standards do not allow a double colon separator to appear in an expression, and so the problem does not arise in those standards. When type specifications were added to array constructors in Fortran 2003, this case was overlooked. Constraint 725 is too clever. Its intended purpose is not obvious. It is enforcing a local condition using a global rule. The intent is to allow the optional comma in cases similar to those for the optional comma in a DO-statement. An edit to 18-007r1 is provided. EDIT to 18-007r1: [7.4.4.2 "Character type specifier" p3+, page 62:14-15] Replace constraint C725 with "C725 The optional comma in a shall be immediately followed by an ." {The BNF reference is not helpful.} SUBMITTED BY: Robert Corbett HISTORY: 20-152 m222 Submitted 20-152r1 m222 Revised edit and alternative 20-152r2 m222 Revised edit - Passed by J3 meeting ----------------------------------------------------------------------