Kickstarting proposals for F202Y features

Now when F2023 (=F202X) is in the final stages, the window has opened to propose and discuss new ideas for F202Y. Please read @sblionel’s post in the WG5/J3 mailinglist about the details how proposals will be considered.



The list of proposals in the last bullet point contains every single issue from the fortran_proposals repository that was ever created, categorized based on which “clause” (chapter) of the standard it should go into, or “Other” if it does not easily fit into one clause, or “Not considered” (If it is a F2023 feature, duplicate, meta, rejected issue), or “Closed” (issues that were closed for various reasons). The list was created by a script that downloads all issues and based on the labels creates the summary document automatically. I’ll be updating this list as new issues are added (or labels changed). We are also thinking it might be a good idea to add this list into some section at the website, please let us know what you think.


The main motivation is to make the committee more transparent and connected with the wider community, and to open up a two-way communication channel about every proposal. The fortran_proposals github repository has many members of the Fortran Standards Committee actively participating. This Discourse forum as well. I counted about 10 here at Discourse and even more at the fortran_proposals repository. Consequently I think the communication is working and we have good participation of the wide community as well as committee members.

What we need now is the participation of the whole Fortran community to suggest ideas for the language and help develop them, so that the committee could standardize them. All you have to do is to discuss and open up new issues at the fortran_proposals, and help develop issues that you like further. Please share this message with your colleagues and try to collect ideas from them and make sure they are in.

If you have any questions, suggestions or feedback, please let us know.


In my opinion, features that can enable the community to build robust, reusable and flexible libraries should be absolute top priority. This includes at least

  • Error handling
  • Metaprogramming
  • Generics

I really like this wishlist:


@fortran4r That’s a good one. I like a lot of those, and in fact we already have issues open for most of these and they usually have a lot of “likes”. I am hoping we can get some of these into F202Y!


I think that namespaces like proposed in the linked thread would be nice, especially for cleanig up older code that contains a lot of global variables or functions to avoid naming conflicts or long lists of entities after the ‘only’ restiction.

However I no language designer and currenty no longer employed in the field of scientific computing, so take my opinion with a grain of salt.


All those plus In the “error handling” item I would like an “abrupt halting mode”, since present current mode is imprecise.

1 Like

@conradoat Can you please open up an issue at GitHub - j3-fortran/fortran_proposals: Proposals for the Fortran Standard Committee and add details to what you would like to see, ideally with examples, regarding your “abrupt halting mode” idea? Let’s discuss it more there.

Yes, I will study the format and will submit a document.

1 Like

@fortran4r , @certik , and other readers who like that wishlist,

If you like the 4th item on that list that states “Make implicit none always active in free form, or at least the default in free form”, then can you try to upvote the following item at Fortran proposals site:

This proposal effectively strives to make implicit none the default. Note the proposal tries hard to maintain backward compatibility, it has no impact on IMPLICIT statements and thus existing codebases which use IMPLICIT whether implicit none or otherwise are not be affected.


Does the number of Github issue upvotes increase the probability of a feature being accepted?

1 Like

@fortran4r yes, but not directly. :slight_smile: If it has lots of upvotes, it is easier for me and others to sell it to others at the committee. The ultimate way to get a feature being accepted is to convince the committee to accept the paper.

Can we have an intrinsic sort subroutine in F202Y?

Can we have an intrinsic sort subroutine in F202Y?

If you want that, then go ahead and upvote this issue:

1 Like

And after you upvote the proposal, try the sorting subroutines from the standard library.