I will tweet a link to the post below by Boleslaw K. Szymanski. Updating it for Fortran 2018,
I would mention that derived types can have allocatable components and that you can initialize a pointer to null() in the declaration. What other updates should be made?
Over the years we have made lots of interesting and fun mistakes in Fortran 90 that we would like to share with you. We welcome your contributions and experiences so that we can share your pain.
Topics
These “gotchas” are nasty because they will not fail on some machines, while failing on others (given various combinations of compilers and machine platforms).
Perhaps this would be more accurately titled “misconceptions and errors”, but then it wouldn’t get the clicks. I’ll mention that ISO’s WG23 “Programming Vulnerabilities” is developing documents that describe error-prone usages in multiple languages. WG5 has been working with WG23 on a “Fortran appendix” for many years.
Well the text under “A surprise with non-advancing I/O” is a bit out of date I don’t know of anyone who thinks that non-advancing I/O is at all comparable to stream I/O in other languages, mainly because Fortran has had for many years a true stream I/O of its own (2003 Standard I think). Which means the statement that all Fortran I/O is record-based is no longer true.
I encountered this issue when I started using Fortran. Now I strictly separate declaration and initialization. I think this issue should be mentioned in the Fortran best practices mini-book because it is so unexpected to those who use C/C++.
It’s mentioned here: Gotchas — Fortran90 1.0 documentation, we just didn’t have time to port it to fortran-lang yet. Would you have time to submit a PR with this addition? That would be really helpful.
Oh wow, I did not realise this was a thing, I always presumed it was just a space saver. Hopefully I’ve only missed this because I don’t tend to use locally initialized variables, rather than now having bugs all over my code…!
IMHO, the Standard should requireSAVE attribute (or separate statement) with all variables which should be actually saved. As it is now, it makes the code less clear. I thought we were going away from any IMPLICIT-ness
That would be very nice! I am aware of this pitfall, but have still made such mistakes myself when coming back to Fortran after using other languages for a while.