J3/98-124 Date: 16 Feb 1998 To: J3 From: R. Maine Subject: Explicitly typed array constructors I. The problem (justification) Array constructors suffer from several problems that I attribute to the "feature" that their type and type parameters need to be inferred from the components. One example that resurfaces continually is the necessity to explicitly pad out all of the strings to the same length in an array of strings, as in (/ 'tom ', 'dick ', 'harry' /) Interpretation 30 on this subject caused considerable anguish, but no adequate answer other than "yes, it is required" emerged. Users continually trip over this requirement and complain vehemently. Another case, which does not yet seem to have been addressed, is raised in the interpretation request in J3/98-101. With parameterized derived types, the opportunity for confusion and complication in this area increases. This is because there are now more cases where the type and type parameters need not be known at compile time. Prior to parameterized derived types, the character length parameter was the only type parameter not constrained to be known at compile time (in the usual weasel words of the standard, where we avoid actually saying "compile time"). II. Specification and syntax I certainly do not propose radically changing array constructor syntax. The existing syntax 1. Is by now used in innumerable codes, pretty much ruling out incompatable changes. and 2. Is fine for the simple cases. My proposal is to add an optional new part to the syntax. This new part would be an explicit specification of the type and type parameters at the beginning of the constructor. If the optional new part is omitted, we have the existing array constructor; the type and type parameters are inferred from those of the elements. If, however, the new part is used to explicitly specify the type and type parameters, then assignment semantics are used for each element; there is no need for the elements to be of the same type and type parameters, or for there to be any elements). The new part would just be a type-spec, which we have already defined syntax for. That sytax works fine in this context. Samples character(len=16) (/ 'tom', 'dick', 'harry' /) real(kind=kind(0.0d0)) (/ 1., 2, 3.d0 /) !-- Note that the second element above is integer. my_pdt(kind=1, dim=3) (/ element1, element2, ... /) We could possibly require the last sample above to be written as type(my_pdt(kind=1, dim=3)) (/ element1, element2, ... /) but I think the type() to be just extra typing to no obvious benefit. I'm flexible on this point though. All of the above forms appear to me to "work" and be unambiguous. They are all a bit wordy for the simple cases. But you don't need to use the extra words for the simple cases. They are optional. This proposal seemed to meet with reasonably good reception in discussion on comp.lang.fortran in response to at least two separate cases of people rediscovering the annoying array of strings limitation of the existing syntax. As best as I can see, the *ONLY* place that would need edits would be section 4.5. They don't seem hard to do. I'm a bit tired to do a good job of them tonight, so I'll see how this proposal floats as is first.