How can we know in which Fortran standard a new feature appeared?
For example, I am happy to have discovered the compiler_version() and compiler_options() functions in Milan’s book.
I can look in my reference book “Modern Fortran explained” (latest version), but it does not tell me when the feature appeared. I could also look in the Fortran 95/2003 version of the book. But I have not the 2008 version.
I can look in the Fortran standards, but it does not seem to contain the information I need. Same scenario: I would be obliged to search in the PDF of all recent Fortran standards until I can’t find the feature.
I can write a short program and use the -std= option of my gfortran compiler and test the latest standards until I encounter an error. I can even do it very quickly with fpm: $ fpm build --flag --std=f2003
I can search the function in the documentation of my compiler. And it’s the fastest method I know, the info is generally available in the case of the gfortran doc, for example: COMPILER_VERSION (The GNU Fortran Compiler)
But is there somewhere a page or document with a list which could tell us quickly in which standard a feature was introduced?
And, as a compiler is able to know if a feature is in a specified standard, we can imagine there is a file in its code containing the information. And if it is open-source we could access that file…
The Introduction clause of the ISO documents for recent standards has a full list of what is changed from the previous standard. The current editor is fairly insistent that this list be complete. One could collect the information from each standard and try to organize it in some useful fashion.
The simplest way to see easily would be to have a Fortran textbook/guide that used colored fonts to indicate the standard when a particular feature was introduced or significantly modified. This would be an enormous amount of work, of course
@pmk that’s a great cheat sheet. Did you make it? If yes, would you like to author it on Learn Fortran - Fortran Programming Language? I’d help put it up and you’d just have to review and approve it. I think it would help many people, and we could build on it as Fortran evolves.
In F66 subprograms needed explicit RETURN statements. Proof:
8.3.1.1(4) says “The function subprogram must contain at least one RETURN statement.”
8.4.1(5) says “The subroutine subprogram must contain at least one RETURN statement.”
In F77 all three of Alternate Return, ENTRY statements and arrays with lower bounds other than 1 were allowed, and RETURN statements were not compulsory. 11.14 says “The END statement indicates the end of the sequence of statements and comment lines of a program unit (3.5). If executed in a function or subroutine subprogram, it has the effect of a RETURN statement (15.8).”
In F77 Hollerith constants and data were deleted, not merely obsolescent. The H edit descriptor in a format was allowed in f77, obsolescent in f90, and deleted in f95.
In f77 .EQV. and .NEQV. were allowed. That answers the question about whether they came later.
PUNCH statements were not allowed in f66, f77 or f90. They were in all the FORTRAN dialects
listed in Daniel D. McCracken (1961) “A Guide to FORTRAN Programming”, Wiley, Appendix 1, which does not mention FORTRAN II explicitly. McCracken (1972) “A Guide to Fortran IV Programming” 2nd ed., Wiley, p.137 says “many modern Fortrans still accept these statements though they are not part of ANSI Fortran.”
I like the cheat sheet but I suggest that when pmk revises it, each Fortran version should start with its new features, followed by its newly obsolescent features, then its newly deleted features. That will make it easier to use.
Just a remark. Both lists show DATE_AND_TIME() subroutine’s last argument, VALUES as an array of 8 values of INTEGER(KIND=8) which seems to be not-standard-conforming. The standard says default integer array. Moreover, the KIND=8, apart from being compiler-specific, is NOT the default integer kind in GFortran (4)
I only wonder whether in the GFortran docs, it is just a mistake in the description or the subroutine really expects an array of kind=8 integers.
EDIT: it is a generic procedure, so it works equally well with both kind=4 and kind=8 arrays
I have one correction (I think): under Fortran 90 obsolescent features you include assumed-length CHARACTER*(*) - but I think that is still useful as the best way to handle strings passed over to procedures, and it appears in an example in the current Fortran 2018 (18-007r1.pdf) near the bottom of page 236. So in my view not obsolescent at all.
I think you have misunderstood. The Fortran 2018 Standard marks as obsolete assumed-length character functions, that is functions where the result is assumed length. I was pointing out that declaring a dummy argument of a procedure to be CHARACTER(LEN=) or CHARACTER(*) is perfectly good current practice. The reference to this in your list of new and obsolete features does not distinguish these rather different cases and so could be misleading.
Jane Sleightholme and I maintain compiler standard conformance tables. If you visit Fortranplus | Fortran information you will find a link to an article that appeared in the April 2020 edition of Fortran Forum. This summarises information for the 2008 and 2018 standards. There is also a link underneath to an article that appeared in the August 2019 edition of Fortran Forum. That has details of earlier standards. Here is a direct link to this directory. Index of /fortran/fortran_forum Hope this is of some use.
Sorry to revive such an old thread but I have got sort of a deja vu. I have had in my memory that it existed and was even able to find it. But now as I re-read it, I am confused. Both links contained in @interkosmos’ solution point to lists of intrinsic procedures but they lack changes to the language itself (new constructs, I/O specifiers etc.). Then at least 2 posts mention (and praise) @pmk for a cheat sheet . But I cannot find the sheet, as if it were deleted??? I have even tried to make a search for two quotes of the @pmk post, to no success. Any pointers?
This link is likely closest to the gist of the title of this thread and what you may be looking for:
Kudos and thanks to Ian Chivers (@cmaapic) and Jane Sleightholme for serving the Fortranners thus far with their work at fortranplus.co.uk.
Perhaps it can be a Fortran community effort now to collaborate with the fortranplus.co.uk team and others to maintain a similar “database” at GitHub / fortran-lang that can offer multiple/different “views” into the data and information?