Deprecate D edit descriptor

[sblionel]

The D format edit descriptor is a relic of the original (1957) FORTRAN, where DOUBLE PRECISION was a distinct datatype from REAL. It no longer serves a useful purpose, and was not extended when variants of the E descriptor (Ew.dEe, EN, ES) were added, so there is already an asymmetry. The various E edit descriptors can be used for all REAL kinds.

I propose adding the D edit descriptor to the Obsolescent list for 202Y. This would not affect the use of D as an exponent letter in literal constants or in formatted input.

[klausler]

All of the six Fortran compilers to which I have access emit 0.10D+09 for PRINT '(D10.2)', 1.0D8. Other output forms would be conforming (0.10E+09, 0.10+009) but that's what you get today.

Q format output editing is a thing in XLF, and it's just like D except for the letter that comes out before the exponent. You don't have to worry about deprecating it (obviously) but maybe it exists because some users like to see visual cues of precision in the output of some programs.

While you're at this, consider also deprecating or deleting 0.10+009 (with no E or D) as a conforming option for the output of (Ew.d) (no Ee). I can't find an implementation that emits it, and it may be an truly dead aspect of the language.

[sblionel]

No, 0.10+009 would not be standard-conforming. The standard specifies omitting the exponent letter only if the decimal exponent is between 100 and 999. This could not be deprecated, unless you wanted to introduce an incompatible change in behavior (such as filling the field with asterisks.) It's also not a syntax term that could be deprecated. But see also https://j3-fortran.org/doc/year/21/21-172.txt

(Intel Fortran currently has a bug where it will emit .10+009 for that value with an E0.2E3 format, and similar any time w=0. I reported it.)

Q as an edit descriptor has different meanings across compilers. In the DEC-heritage compilers it is used during input and transmits the number of remaining characters in the record to the next list item.

[klausler]

Please refer to table 13.1 in Fortran 2018; the part for "Dw.d" allows "D+zz", "E+zz", or "+0zz" when ABS(exp)<=99. At least in my PDF.

[sblionel]

Ah, right - somehow I overlooked that. I haven't ever seen an implementation choose that.

[sblionel]

I suppose it would be feasible to remove that alternate form from the standard - we have changed behaviors before. It wouldn't invalidate any existing programs, but compilers claiming to support the new standard simply wouldn't emit that form (not that I think any do now.)

[jeffhammond]

I guess it's trivial for me to fix it, but I would have to modify about 5% of NWChem to be compliant after this change.

% git grep "[0-9]D[+=0-9]" "*.[fF]" | wc -l
  140778

[klausler]

I guess it's trivial for me to fix it, but I would have to modify about 5% of NWChem to be compliant after this change.

% git grep "[0-9]D[+=0-9]" "*.[fF]" | wc -l
  140778

I think this proposal would only affect Dw.d edit descriptors in FORMAT statements and dynamic format strings, not literal real constants, which your pattern is probably also counting.

[jeffhammond]

@klausler There are less than 20 uses in format/write, which I could fix in a few minutes.