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.


Can we have option for defining ternary operators. I am not much interested in the conditional operator (:? pair). But, I would love to overload axpy, e.g., by a*x+y.

1 Like

How would such an operator look-like in practice?

interface operator({1} + {2} * {3})  
      ! use position place-holders {} to pass arguments
   module procedure multiply_add
end interface

type :: vector
   real :: x(3)
end type


subroutine multiply_add(y,a,x)
type(vector), intent(inout) :: y
real, intent(in) :: a
type(vector), intent(in) :: x
y%x(1) = y%x(1) + a * x%x(1)
y%x(2) = y%x(2) + a * x%x(2)
y%x(3) = y%x(3) + a * x%x(3)
end subroutine

Wouldn’t this mean bringing a new type of statement (besides call, assignment, write, print,…)?

type(vector) :: a, b
real :: c

c = 2
a = vector([1.,0.,0.])
b = vector([0.,1.,1.])

call multiply_add(a,c,b)
! or
a + b*c   ! effectively a := a + b*c

IEEE_fma has a different order of arguments, I would suggest to stay consistent.

Conventions differ; I was following the Wikipedia page on multiply-add which describes it as the operation a \leftarrow a + (b\times c). Multiply-add was not my focus. I was only interested how a ternary operator could look like. It seems like a nice idea at first, but would you allow it only for functions (i.e. expressions) or also as a in-place substitute for assignment? As far as I can understand, a ternary operator would be syntactic sugar for:

call f(a,b,c)
y = f(a,b,c)
a = f(b,c)

where a,b, and c are the arguments in the ternary expression

The Wikipedia page on ternary operations doesn’t give any example I found particularly compelling. I found a Julia issue (Customizable Ternary Operators · Issue #39353 · JuliaLang/julia · GitHub), but the author used a macro in the end.

1 Like

I’ve never thought about this because the conditional operator and FMA (for performance reasons) are the only ternary operators I’m using. AXPY—Wolfram Language Documentation looks like a special case of the more general addition assignment, e.g. a+=b*c in Python. I would love to have that in Fortran, even though the attributed performance improvements are probably not existent for modern compilers.

So, may be quaternary operator is what I am looking for containing =, * and +.