# Which five features should Fortran 202Y implement? **URL:** \ **Category:** Uncategorized\ **Created:** [July 11, 2022, 6:45pm UTC](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977 "2022-07-11T18:45:43Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\ **Post date:** [July 11, 2022, 6:45pm UTC](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977/1 "2022-07-11T18:45:43Z")
Here is a list of ideas: - [Issues · j3-fortran/fortran\_proposals · GitHub](https://github.com/j3-fortran/fortran_proposals/issues) - [j3 04232022 · Wiki · fortran-lang / github\_stats · GitLab](https://gitlab.com/fortran-lang/github_stats/-/wikis/j3-04232022) and you can propose more if your idea is not on the list. Then each member of the Fortran Committee proposes 5 features they would like to see. To begin the “down select” discussions. What five features do you want me/us to represent? It seems the top two for me would be: - Generics - Better error handling (not necessarily exceptions), see e.g.: [Exceptions in Fortran · Issue #236 · j3-fortran/fortran\_proposals · GitHub](https://github.com/j3-fortran/fortran_proposals/issues/236) As in my opinion these are needed for a longevity of Fortran. The other three might be issues that I see every single newcomer to hit: - Eliminate implicit typing by default: [Eliminate implicit typing · Issue #90 · j3-fortran/fortran\_proposals · GitHub](https://github.com/j3-fortran/fortran_proposals/issues/90) - Eliminate implied save by default: [Deprecate and remove implicit save behavior · Issue #40 · j3-fortran/fortran\_proposals · GitHub](https://github.com/j3-fortran/fortran_proposals/issues/40) - Somehow fix the issue of mixed precision (e.g. this `real(dp) :: x = 3.3` not doing what a newcomer would expect): [Default KINDs for constants and intrinsics · Issue #78 · j3-fortran/fortran\_proposals · GitHub](https://github.com/j3-fortran/fortran_proposals/issues/78) 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. Let me know your thoughts. ---
**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\ **Post date:** [July 11, 2022, 7:18pm UTC](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977/2 "2022-07-11T19:18:25Z")
My top 3 would be (in order of importance to me) 1. Better generics (something I think we all agree on) 2. 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. 3. 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 1. 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) 2. 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. ---
**Author:** ![fortran4r](https://avatars.discourse-cdn.com/v4/letter/f/9de0a6/32.png) [@fortran4r](https://fortran-lang.discourse.group/u/fortran4r)\ **Post date:** [July 11, 2022, 8:09pm UTC](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977/3 "2022-07-11T20:09:06Z")
1. implicit line continuation 2. intrinsic functions providing a standardized modern interface to blas/lapack 3. 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. ---
**Author:** ![MarDie](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/mardie/32/54_2.png) [@MarDie](https://fortran-lang.discourse.group/u/MarDie)\ **Post date:** [July 11, 2022, 8:09pm UTC](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977/4 "2022-07-11T20:09:48Z")
For me, new features would be 1. Namespaces: [Namespaces · Issue #87 · j3-fortran/fortran\_proposals · GitHub](https://github.com/j3-fortran/fortran_proposals/issues/87)) 2. Better error handling (not necessarily exceptions): [Namespaces · Issue #87 · j3-fortran/fortran\_proposals · GitHub](https://github.com/j3-fortran/fortran_proposals/issues/87) 3. Generics and in addition I would like to see changes for the behavior related to 1. implicit typing: [Eliminate implicit typing · Issue #90 · j3-fortran/fortran\_proposals · GitHub](https://github.com/j3-fortran/fortran_proposals/issues/90) 2. precision handling, e.g. removing the constraint that the default integer and the default floating point representation need to occupy one “storage unit” ---
**Author:** ![milancurcic](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/milancurcic/32/2_2.png) [@milancurcic](https://fortran-lang.discourse.group/u/milancurcic)\ **Post date:** [July 11, 2022, 8:15pm UTC](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977/5 "2022-07-11T20:15:06Z")
1. Generics 2. Namespaces 3. Better error handling 4. Unsigned integers 5. Default values for optional arguments ---
**Author:** ![epagone](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/epagone/32/252_2.png) [@epagone](https://fortran-lang.discourse.group/u/epagone)\ **Post date:** [July 11, 2022, 9:11pm UTC](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977/8 "2022-07-11T21:11:23Z")
1. [Generics](https://github.com/j3-fortran/generics) 2. [Allow setting default value for optional dummy argument](https://github.com/j3-fortran/fortran_proposals/issues/22) 3. [Namespace for modules](https://github.com/j3-fortran/fortran_proposals/issues/1) 4. [Array of strings](https://github.com/j3-fortran/fortran_proposals/issues/24) (or intrinsic `string` type) 5. [Deprecate and remove implicit save behavior](https://github.com/j3-fortran/fortran_proposals/issues/40) If more than 5 can be suggested, I definitely agree with the remaining 3 proposed by @certik in his first post. Namely, > [@certik](#): > > Better error handling (not necessarily exceptions), see e.g.: [Exceptions in Fortran · Issue #236 · j3-fortran/fortran\_proposals · GitHub](https://github.com/j3-fortran/fortran_proposals/issues/236) > [@certik](#): > > Eliminate implicit typing by default: [Eliminate implicit typing · Issue #90 · j3-fortran/fortran\_proposals · GitHub](https://github.com/j3-fortran/fortran_proposals/issues/90) > [@certik](#): > > Somehow fix the issue of mixed precision (e.g. this `real(dp) :: x = 3.3` not doing what a newcomer would expect): [Default KINDs for constants and intrinsics · Issue #78 · j3-fortran/fortran\_proposals · GitHub](https://github.com/j3-fortran/fortran_proposals/issues/78) ---
**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\ **Post date:** [July 13, 2022, 3:41pm UTC](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977/9 "2022-07-13T15:41:56Z")
28 posts were split to a new topic: [Implicit typing and backwards compatibility](https://fortran-lang.discourse.group/t/implicit-typing-and-backwards-compatibility/3991) ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [July 11, 2022, 9:48pm UTC](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977/13 "2022-07-11T21:48:00Z")
Here are some things I think would be useful: 1. The ability to initialize an allocatable entity at its declaration. 2. The ability to transfer attributes between POINTER and ALLOCATABLE entities. This might be done by extending MOVE\_ALLOC() to allow pointer arguments. 3. Allow expression evaluations in input for NAMELIST and possibly LIST-DIRECTED I/O. 4. An intrinsic bit data type. 5. Standardize a cpp-like preprocessor. 6. 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. ---
**Author:** ![everythingfunctional](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/everythingfunctional/32/176_2.png) [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)\ **Post date:** [July 11, 2022, 9:54pm UTC](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977/14 "2022-07-11T21:54:12Z")
My list at the moment is: - [Usable polymorphism in coarrays](https://github.com/j3-fortran/fortran_proposals/issues/251#) - [Simple Functions in Constant Expressions](https://github.com/j3-fortran/fortran_proposals/issues/253#) - [Enable Polymorphic Outputs From Pure Procedures](https://github.com/j3-fortran/fortran_proposals/issues/196#) - Generics (but that one’s already in the works) These are the features directly preventing me from implementing certain frameworks/libraries in desired ways. ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [July 11, 2022, 10:09pm UTC](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977/16 "2022-07-11T22:09:48Z")
As discussed in [A shorthand for immutability · Issue #221 · j3-fortran/fortran\_proposals · GitHub](https://github.com/j3-fortran/fortran_proposals/issues/221), 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. ---
**Author:** ![fortran4r](https://avatars.discourse-cdn.com/v4/letter/f/9de0a6/32.png) [@fortran4r](https://fortran-lang.discourse.group/u/fortran4r)\ **Post date:** [July 11, 2022, 10:17pm UTC](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977/17 "2022-07-11T22:17:27Z")
It feels weird without the matching end associate. Why not simply put all the expressions in one parenthesis? ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [July 11, 2022, 10:26pm UTC](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977/18 "2022-07-11T22:26:36Z")
That is not allowed if one association depends on another one. For example, you cannot write `associate (x => 2.1, xsq => x**2)` ---
**Author:** ![CRquantum](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/crquantum/32/730_2.png) [@CRquantum](https://fortran-lang.discourse.group/u/CRquantum)\ **Post date:** [July 11, 2022, 10:51pm UTC](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977/19 "2022-07-11T22:51:00Z")
namespace +1 ---
**Author:** ![fortran4r](https://avatars.discourse-cdn.com/v4/letter/f/9de0a6/32.png) [@fortran4r](https://fortran-lang.discourse.group/u/fortran4r)\ **Post date:** [July 12, 2022, 12:34am UTC](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977/20 "2022-07-12T00:34:25Z")
Is it possible to allow this? In languages like R, this is allowed since codes are evaluated from left to right. ---
**Author:** ![fortran4r](https://avatars.discourse-cdn.com/v4/letter/f/9de0a6/32.png) [@fortran4r](https://fortran-lang.discourse.group/u/fortran4r)\ **Post date:** [July 12, 2022, 12:56am UTC](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977/21 "2022-07-12T00:56:45Z")
`https://stackoverflow.com/questions/tagged/fortran?tab=Frequent` 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. ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [July 12, 2022, 2:02am UTC](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977/22 "2022-07-12T02:02:56Z")
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 - 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. ---
**Author:** ![Euler-37](https://avatars.discourse-cdn.com/v4/letter/e/b19c9b/32.png) [@Euler-37](https://fortran-lang.discourse.group/u/Euler-37)\ **Post date:** [July 12, 2022, 2:34am UTC](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977/23 "2022-07-12T02:34:57Z")
1.Array interation. [for loop · Issue #241 · j3-fortran/fortran\_proposals · GitHub](https://github.com/j3-fortran/fortran_proposals/issues/241) 2.change default constant kind to real(8) or infinite. [Default KINDs for constants and intrinsics · Issue #78 · j3-fortran/fortran\_proposals · GitHub](https://github.com/j3-fortran/fortran_proposals/issues/78) 3. remove implicit save behavior. [Deprecate and remove implicit save behavior](https://github.com/j3-fortran/fortran_proposals/issues/40) 4. pattern matching. [Unpacking variables from arrays · Issue #186 · j3-fortran/fortran\_proposals · GitHub](https://github.com/j3-fortran/fortran_proposals/issues/186) ---
**Author:** ![shahmoradi](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/shahmoradi/32/3151_2.png) [@shahmoradi](https://fortran-lang.discourse.group/u/shahmoradi)\ **Post date:** [July 12, 2022, 5:03am UTC](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977/26 "2022-07-12T05:03:44Z")
My preference would be: 1. Generics 2. Somehow fix the issue of mixed precision 3. A standardized and portable module format 4. **multiline string support** , something like Python docstrings (highly useful when combined with preprocessing for multilingual coding and library documentation): ```fortran 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. ---
**Author:** ![snano](https://avatars.discourse-cdn.com/v4/letter/s/fbc32d/32.png) [@snano](https://fortran-lang.discourse.group/u/snano)\ **Post date:** [July 12, 2022, 8:38am UTC](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977/28 "2022-07-12T08:38:58Z")
- string handling through intrinsic procedures. ---
**Author:** ![zoziha](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zoziha/32/582_2.png) [@zoziha](https://fortran-lang.discourse.group/u/zoziha)\ **Post date:** [July 12, 2022, 8:51am UTC](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977/29 "2022-07-12T08:51:31Z")
1. Generics; 2. Default `implicit none`; 3. Namespaces; Optional: 1. Real numbers default to double precision; 2. Built-in data structures: Hash table (map). [Next page](https://fortran-lang.discourse.group/t/which-five-features-should-fortran-202y-implement/3977.md?page=2)