These are not as critical, as it should be possible to catch or workaround with a good compiler (with warnings and/or errors), but I think it would still be good to just make the standard itself not even allowing these in the first place.
There are more people on this forum who are part of the committee, so more than 5 features can be added.
Better generics (something I think we all agree on)
A standardized and transportable module format to eliminate the need to compile different versions of say MPI for example if you want to USE mpi08 etc. I doubt this will ever happen though but it would make building libraries that can be used by any compiler a lot easier.
Eliminate the need for implicit NONE one way or the other.
I see the need for better error handling. It’s just not as important for me as my top 3.
Edit
Outside of error handling, the only other things I would like to see are a couple of small cosmetic changes that I think would be trivial to implement
Eliminate the need to prefix CALL to every subroutine reference when an explicit interface exists for the subroutine. This is aimed at newcomers who are used to the way every other major language references a void function (AKA subroutine)
Add a deallocate option to allocate that says if something in the allocate list is already allocated, go ahead and deallocate it for me and reallocate to my requested new size. This would save the extra code required to check for allocation with an if (allocated()) statement.
intrinsic functions providing a standardized modern interface to blas/lapack
namespace
And also, the three newcomer confusions mentioned in the main post. I have accepted to live with them, but they are major obstacles for new users due to their weirdness and lack of documentation. Getting rid of them may be more important than introducing new features in terms of boosting new user adoption.
precision handling, e.g. removing the constraint that the default integer and the default floating point representation need to occupy one “storage unit”
The ability to initialize an allocatable entity at its declaration.
The ability to transfer attributes between POINTER and ALLOCATABLE entities. This might be done by extending MOVE_ALLOC() to allow pointer arguments.
Allow expression evaluations in input for NAMELIST and possibly LIST-DIRECTED I/O.
An intrinsic bit data type.
Standardize a cpp-like preprocessor.
Allow allocatable entities to be allocated and defined within i/o statements. This would allow, for example, an array of unknown size to be simply read in a natural way.
As far as I know, none of the above would break backward compatibility, they are all extensions of the language beyond its present limits.
As discussed in A shorthand for immutability · Issue #221 · j3-fortran/fortran_proposals · GitHub, I would like end associate to be made optional. The association would end at the end of a program unit. If associate were streamlined in this way, it might be used more often, and a large fraction of declarations would be unnecessary, giving Fortran some of the convenience of Python/Julia/Matlab/R. By associating a name to an expression one can generalize the concept of the named constant (parameter), which must be known at compile time.
Out of the 15 most frequent Fortran questions on Stack Overflow, three are related to data type. The 1st and 2nd are about kind, and the 13th is about double precision.
Since Fortran is a compiled language, the first thing a newcomer needs to learn is the data type. I personally believe this confusion in the first step has driven away many potential users and given many more a wrong impression about Fortran. Instead of making any breaking changes, having better tutorials is much easier and more efficient.
Hmmm, the problem is next week my list will be different. Depending on what has happened recently it might be weighted towards parallelism or more intrinsics or … But for the moment at least
additional intrinsic types – intrinsic lists, arrays of string type
with varying length, and unsigned integers and/or a bit type (given an
retro unsigned integer could be a lot of work for compiler developers)
like LOGICAL used to be on some platforms.
Block text for defining character arrays and comments
Namespace for module entities (where a module name can be used as
a prefix) and automatic generics for name collisions from two modules
when the procedures are distinguishable by their interfaces
Default value specification in the procedure definition that is NOT
implicitly saved, as in
subroutine a(par1=10,par2=[10.0,20.0,30.0])
that uses the same syntax as NAMELIST groups for defining user types and repeats,
with the difference that allocatable entities could be given defaults,
which would be used for unallocated dummy arguments or intent(out) intents.
standardized basic LA and low-level graphics libraries
Others …
namespace access for at least some variables combined with allowing
expression evaluation, and ability to ignore unused values in NAMELIST
and write partial NAMLIST groups based on an argument list, like “write(,nml=big) a,b,c"
or even something more like a USE statement "write(,nml=big) only :: a,b,c”
Standardized preprocessor.
Regarding personal solutions to some of the questions/comments above
How to flag not to use deprecated features:
As a suggestion, I personally use the name of the standard not to say to
enforce that standard, but to enforce not using everthing deprecated by
that and previous standards, plus being free-format and having an implied
“implicit none”.
I make the first line !standard, ie. “!f2018” and use that as
a flag to turn on compiler switches for everything deprecated by that or
previous standards (it uses the file(1) command and a magic file on *nix
systems and a simple wrapper). All the compilers I use have a switch
to assume “implicit none”, very long or unlimited line length, and so on.
Not perfect, but handy. If there were a “–no-deprecated=f2020” switch
that vendors would support that would be nice.
multiline string support, something like Python docstrings (highly useful when combined with preprocessing for multilingual coding and library documentation):
character(:), allocatable :: multiline
multiline = """
s
t
r
i
n
g
"""
Thank you, @certik, and all (committee members and community volunteers) for your active role in formalizing and making progress on these enhancements.