search

j3-fortran / fortran_proposals

Proposals for the Fortran Standard Committee
178 stars 15 forks source link

Deprecate D edit descriptor #226

Open sblionel opened 3 years ago

sblionel commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

sblionel commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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