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.
Please upvote proposals that you like and discuss existing proposals in the issues
If some issue can have its title improved, or merged with another issue, or closed or labeled differently, please let us know in the issue; please help us polish them
You can also discuss new features here at Discourse, if you want to brainstorm some ideas, before creating a proposal
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 https://fortran-lang.org/ website, please let us know what you think.
Motivation
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
@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.
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.
@fortran4r yes, but not directly. 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 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.
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
contains
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
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
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.
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.