Which five features should Fortran 202Y implement?

[jeremie.vandenplas]

My preferences would be:

1. Generics
2. Support of default values for optional arguments
3. Namespaces

[themos]

Coroutines and Iterators

[rgaelzer]

Well, I can provide my 0.0005 cents thoughts, FWIW.

1. Unsigned integers.
2. Namespaces.
3. Better generics.
4. Official support for a standard library. This one alone will take care of several requests. IMHO, the J3 committee could sponsor the already existing initiative from the community, namely the GitHub project GitHub - fortran-lang/stdlib: Fortran Standard Library and provide support.

[whuhn]

Really feel the need to disclaimer here that I’m speaking 100% on behalf of myself.

• The first thing that immediately sprung to my mind was standardization of the module format across vendors, because this was a nightmare back when I was pretending to be DevOps for my projects. IMHO, we’ll never move away from MPI header includes as long as modules are incompatible across vendors, no matter how many passive-aggressive messages vendors send to customers about using them, as the average user can’t trust that the sysadmins know about Fortran. (I also don’t think this will happen, though.)
• Agreed about generics, nothing to add that hasn’t been covered.
• Agreed about namespaces, nothing to add that hasn’t been covered.
• The question of error handling needs to be handled very carefully, just saying “better” here isn’t good enough. At one point, exceptions were considered to be “better” than simple return values.
• I feel that “implicit save” and “implicit none” have been combined into one larger argument even though they’re quite different. My $0.02 is that removing “implicit save” would cause difficult-to-debug runtime errors whose resolution wouldn’t make the code that much cleaner, whereas enforcing “implicit none” by default for modern Fortran would lead to relatively easy-to-spot compiler-time errors whose resolution would make the code cleaner.

[Beliavsky]

@whuhn

My $0.02 is that removing “implicit save” would cause difficult-to-debug runtime errors whose resolution wouldn’t make the code that much cleaner

I favor eventually removing

subroutine foo()
integer :: n = 42

from the language. First it could be declared obsolescent. A user who wants this behavior should write

integer, save :: n = 42

I agree with you that changing the meaning of the first code fragment would cause run-time errors and should not be done. As suggested by @certik, a new syntax could be introduced, such as

integer, init :: n = 42

equivalent to

integer :: n
n = 42

[paprof]

My top 3 would be (in order of importance to me)
1. Generics
2. Namespaces
3. Deferred rank arrays (to allow for the creation of a single subprogram that could
utilize whole array operations to implement algorithms using arrays of arbitrary
rank)

[certik]

Thank you everybody who commented so far (@paprof welcome to the forum!), keep it coming.

There was a very important discussion here about how to handle implicit typing going forward, which I split into a dedicated thread here (this topic requires a deep discussion):

Implicit typing and backwards compatibility

Note 7/13/2022: I split this thread from Which five features should Fortran 202Y implement?. Unfortunately the first comment that started the discussion was deleted, but here is the rest of the discussion starting from the second comment: @kargl you are correct that these behaviors are well documented (including in the standard) and well-known to experienced practitioners of Fortran, but when I teach Fortran to people who don’t know it, these are the very first issues that every single beginne…

So that we can keep this thread to just suggestions to present to the standards committee.

[simong]

1. Generics (which I assume means some type of templating functionality)

2. Endow the standard ‘do’ loops with the index syntax of ‘do concurrent’. This would get rid of the many annoying integer :: i, j,k … declarations I’ve had to make over the years.

3. uniform module grammar

4. Allow variable types on the lhs of an expression to be inferred like ‘auto’ in C++ either using a new keyword
   auto_type :: i, j, k
   …
   i = 1
   j = 2i
   k = 2j +1

or, in an effort to cut down the number of declaration lines a different assignment symbol:
i <= 1
j <= 2i
k <= 2j +1

5. namespaces

[Beliavsky]

@simong

4. Allow variable types on the lhs of an expression to be inferred like ‘auto’ in C++ either using a new keyword
   auto_type :: i, j, k
   …
   i = 1
   j = 2i
   k = 2j +1

You can currently write

associate (i => 1)
associate (j => 2*i)
associate (k => 2*j + 1)
...
end associate ; end associate ; end associate

and I have suggested upthread making the end associate statements optional.

[St_Maxwell]

• deprecate implicit none statement and force explicit typing
• literals of real numbers and real type variables are double precision (real64) by default
• unsigned integers
• formal standard library (why not? we already have iso_fortran_env, iso_c_binding and ieee_xxx. I think something like iso_fortran_sort is very natural)
• production-ready string type and related procedures
• literals of multi-dimensional arrays (e.g. [[1,2];[3,4]])
• generics (I put it last because I have no expectations about it)

[fortran4r]

Can we just move on with the non-breaking features? I understand that typing implicit none is annoying, but adding a compiler flag can easily solve it. Just make implicit none the default in fpm and make fpm the mainstream tool for Fortran users.

[NormanKirkby]

Open and inquire on URL =?

[certik]

@fortran4r Can you please send a PR to fpm?

[RonShepard]

@Beliavsky

I agree with you that changing the meaning of the first code fragment would cause run-time errors and should not be done. As suggested by @certik, a new syntax could be introduced, such as

integer, init :: n = 42

equivalent to

integer :: n
n = 42

The thing I don’t like about this suggestion is that, as you show, there is already a simple, straightforward, and clear way to achieve the same result. Adding INIT or NOSAVE or whatever is the new keyword is redundant, and it is just one more unnecessary thing that both programmers and compiler writers would have to worry about.

I always include the SAVE attribute whether the entity is initialized with a data statement or on the declaration line. It is redundant, but it makes it clear what is happening, and this separates the two cases (initialization at compile time and initialization in an executable statement) more clearly. Adding something in the middle, that looks like one thing but is really the other, is not productive. Short of changing the standard and introducing backwards compatibility problems, I think compilers should at least print warnings when an implicitly saved entity occurs in an initialization statement, and if compiler options are available to enforce that, then programmers should be encouraged to use those.

[ashe]

@RonShepard

Short of changing the standard and introducing backwards compatibility problems, I think compilers should at least print warnings when an implicitly saved entity occurs in an initialization statement, and if compiler options are available to enforce that, then programmers should be encouraged to use those.

Do any compilers (or style checkers) warn about this? The consensus here (which I agree with) is that it is bad practice, but I haven’t ever seen warnings about it.

[urbanjost]

INCLUDE too; which would technically not be non-standard even now (the definition of what the argument to an INCLUDE directive is pretty general. An INCLUDE that would get files like curl(1) or wget(1) is something I have wanted in the past; picturing something like a netlib repository or github/gitlab/… repositories. Not aware of any compilers that take anything but a filename. I made a preprocessor directive that you could give commands to like wget(1) or even echo(1) commands to get things like environment variables that was useful, but have to be used judiciously with general commands ot you can very quickly get very OS-dependent; a URL is less general and safer. If you did allow a process like popen(3c) does it really would not work with INQUIRE but would be really useful.

[awvwgk]

@certik

@fortran4r

Just make implicit none the default in fpm and make fpm the mainstream tool for Fortran users.

@fortran4r Can you please send a PR to fpm?

Here is a quick and hacky patch for making implicit none the default for one compiler in fpm using the option build.implict-typing in the manifest:

Add option for implicit none as default

Full details on the implementation are available in Support disabling of implicit typing in package manifest · Issue #577 · fortran-lang/fpm · GitHub. The overall setup needs more thoughts before this can be become a proper patch for fpm. If anyone wants to take this up, feel free to comment in the linked thread.

[RonShepard]

@urbanjost

INCLUDE too; which would technically not be non-standard even now (the definition of what the argument to an INCLUDE directive is pretty general. An INCLUDE that would get files like curl(1) or wget(1) is something I have wanted in the past; picturing something like a netlib repository or github/gitlab/… repositories. Not aware of any compilers that take anything but a filename.

I would call the current situation machine-dependent rather than non-standard. Namely, the filename syntax depends on the local file system conventions.

However, this idea of allowing URLs in the include statement is interesting. Currently, this task is accomplished by downloading the remote file to a local file, possibly testing for any differences before replacing the local file, and then invoking the build process. If the include file has changed, then it would presumably trigger any necessary recompilation steps. Sometimes the fetch process itself can determine if the local file needs to be updated (through svn or git or whatever).

There was a recent discussion (in comp.lang.fortran I think) about physical constants that are available online from the NIST web site. The idea was about automating the process of getting the current standard values for physical constants (speed of light, planck’s constant, avagadro’s number, and so on) into a fortran module, which could then be USEd. The constants change every few years as new experimental data is incorporated into the overall dependency scheme, and sometimes the designation of fundamental constant and derived constant changes. This might be accomplished in part with an INCLUDE statement that references a URL.

[CRquantum]

Is it possible to introduce block comment like C++'s /* ... */ in Fortran?
Well, after some google it seems

#if 0
things you want to commented.
#endif

with the -fpp compiling flag can do the block comment trick.

[jacobwilliams]

My top 5:

1. A significant generics feature that allows for creating a composable library ecosystem not just for different real kinds, but also for automatic differentiation.
2. Exception handling.
3. Removal of the bad old language features (implicit typing, implicit save, fixed-form source, etc.). Just delete them all in one fell swoop, there’s no need to trickle these away over decades.
4. A real string class built into the language. That allows us to have arrays of different-sized strings, and also allows use of the slice syntax (something none of the hand-rolled string classes we can write now can do). Must be supported by all intrinsic routines that accept or return strings (read, write, etc.)
5. Some kind of alternate parallelization that works more like Python multiprocessing, where we can on-the-fly launch new processes while the program is running. Must work in libraries written in Fortran, but Fortran may not be the main language (e.g. a library called from Python).