To: J3 J3/21-146 From: Jon Steidel Subject: Request for interpretation: Specification inquiry Date: 2021-June-11 ---------------------------------------------------------------------- NUMBER: F18/028 TITLE: Specification inquiry DEFECT TYPE: Erratum STATUS: J3 submitted meeting 224 QUESTION: Consider the following program: implicit type (t) (a-z) integer,parameter :: n = storage_size(x) type t character(len=n) :: s end type t print *, n end Two compilers tested issue a compile time error message while a third compiler compiled the program and printed "0" when executed. Is the use of storage_size(x) a valid specification expression in this program? DISCUSSION: In the above program, x is implicitly typed to be type(t). It is used in a specification expression requiring knowledge of type(t), prior to the specification of type(t). There is no text in the standard to prohibit this usage. The rules for specification expressions require the type, type parameters, array bounds, and cobounds of a variable to be known via prior specification, or use or host association when the variable is used in a specification expression. If an element of an array whose value is used in a specification expression, the array must be fully specified in prior declarations. The intent is that specification expressions which are constant ex- pressions can be evaluated when seen. ANSWER: No, the program is not conforming. The use of an implicitly typed var- iable of derived type in a specification inquiry prior to the spec- ification of the derived type was overlooked. An edit is provided to correct this oversight. EDIT to 18-007r1: [158:4] 10.1.11 Specification expression p6 Insert at the end of the paragraph: "If a variable in a specification expression is typed by the implicit typing rules and has a type that is a derived type, that type shall be previously defined." SUBMITTED BY: Jon Steidel HISTORY: 21-nnn m224 Submitted ----------------------------------------------------------------------