The post at https://groups.google.com/g/comp.lang.fortran/c/DOC-CNFy3A4 describing some new features of Fortran 202X is interesting.
3 Likes
I had been wondering about the status of 202x, and this seems to be an apropos topic here (the threads about conditional expressions got quite long already). Cross-posting this from a similar comment on a related github issue for visibility, hope that’s alright. 
I had noted that the release was scheduled for October 2023.
John Reid has just put online a 23 pages document entitled The new features of Fortran 202x (March 21, 2022):
Abstract
The aim of this paper is to summarize the new features of the revision of Fortran 2018
that is planned for publication in 2023. It is known informally as Fortran 202x. We take as
our starting point Fortran 2018 (ISO/IEC 2018) and its corrigendum (ISO/IEC 2021).
For an informal description of Fortran 2018, see Metcalf, Reid and Cohen (2018).
NB This article is not an official document and has not been approved by WG5 or PL22.3 (formerly J3).
5 Likes
Some very nice features there indeed, inline conditional statements for example will be very nice.
To me the enumeration type functionality seems rushed and I fear it’s usability will be severely limited. Enum variants should really be namespaced to avoid confusion with variables when reading the code. The example in the PDF
enumeration type :: colour
enumerator :: red, orange, green
end type
type(colour) light
:
if (light==red)
would be much more readable if the syntax was
enumeration type :: colour
enumerator :: red, orange, green
end type
type(colour) light
:
if (light == colour::red)
Also, there does not seem to be any requirement that select case with enums must be exhaustive. This will potentially create maintenance nightmares as seen in other languages without this requirement. For example, Java recently made a new switch syntax with this requirement.
Fortran could really benefit from enums (or tagged unions if you will) inspired by functional programming languages, but instead the standard committee seems to be stuck on the C way of thinking that an enum is a way of naming integers 
Quite a few interesting additions.
If anyone is interested, a prototype version of the upcoming split intrinsic can be found here: GitHub - milancurcic/fortran202x_split: Fortran implementation of the Fortran 202X split intrinsic subroutine
1 Like
Could someone give an example code for the following:
2.3 US 16. The specifiers typeof and classof
The specifier typeof is available to declare one or more entities to be nonpolymorphic with the
type and type parameters of a previously declared entity. The previous entity may have intrinsic
type. It may be polymorphic, in which case its declared type is used; it must not be unlimited
polymorphic or abstract.
The specifier classof is available to declare one or more entities to be polymorphic with the
declared type and type parameters of a previously declared entity. The previous entity must
not be of assumed type or intrinsic type. It may be unlimited polymorphic.
For both typeof and classof, if the previous entity is an optional dummy argument it must
not have a deferred or assumed type parameter, but a type parameter is deferred if it is deferred
for the previous entity and this is not an optional dummy argument.
1 Like
I assume others will have a use for the new enumerator capabilities but I don’t see an immediate use in any of the types of codes I work with. My personal preference would be to
- modify the existing capability to remove the bind(c) nonsense. I use enum quite a bit to set flags that I use as case selectors in SELECT CASE constructs in code that has nothing to do with C interop.
- keep the type name. I remember that the first implementations of enum that I saw was in a pre-F2003 Cray compiler and it allowed a name as an option.
- Allow different data types via a kind parameter and also add an increment value to set a default increment. ie
REAL, PARAMETER :: INC=2.0
ENUM(KIND=REAL32, INCREMENT=INC) :: NUMBERS
ENUMERATOR :: ZERO=0.0, TWO, FOUR, SIX, EIGHT
END ENUM
1 Like
Nice, that means I might still be alive when compilers for common mortals actually support the new features. 
1 Like
yes, only people who know the history of Fortran standard will understand why there is an enum and an enumerator type. For all others, the language will just look strange.
But since backward compatibility is more important than consistency, design flaws will accumulate in the Fortran standard. From the user perspective, this does not make sense. It would be much easier to compile old code with options like -std=77, -std=95 and new code with -std=22 instead of having the one standard fits all approach.
Having versions is a very good means to communicate: “In the face of new knowledge we have revised some design decisions.” A breaking change is not nice, but piling up technical debts is even worse.
The catholic church allows remission of sins, but not the Fortran standard committee because it is infallible 
3 Likes
I think you’re absolutely right in that bind(c) is not what we need here. I find your idea of specifying a kind to the enum interesting, but I don’t like the idea of constraining the whole enum to a single type. One of my main takeaways from functional programming languages and Rust is that enums where variants may have different data types is a really powerful language feature.
As an example, say I want to implement some sort of numerical integrator and I want to support an fixed step algorithm and a variable step algorithm. The parameters passed to the solver subroutine in these two cases will vary, but can be described very well with an enum. Here’s an attempt at showing what I mean:
module solver_mod
use iso_fortran_env, only: dp => real64
implicit none
private
public solve
public integrator_t
public fixed_step_integrator_t
public variable_step_integrator_t
type :: fixed_step_integrator_t
real(dp) :: stepsize
end type
type :: variable_step_integrator_t
real(dp) :: min_stepsize
real(dp) :: tolerance
end type
enumeration type :: integrator_t
enumerator :: fixed_step => type(fixed_step_integrator_t)
enumerator :: variable_step => type(variable_step_integrator_t)
end type
contains
subroutine solve(integrator)
type(integrator_t), intent(in) :: integrator
select type (integrator)
type is (integrator_t::fixed_step)
write(*,*) 'Solving equations with fixed step solver'
write(*,*) 'stepsize: ', integrator%stepsize
type is (integrator_t::variable_step)
write(*,*) 'Solving equations with variable step solver'
write(*,*) 'min stepsize: ', integrator%min_stepsize
write(*,*) 'tolerance: ', integrator%tolerance
end select
end subroutine
end module
program main
use iso_fortran_env, only: dp => real64
use solver_mod
implicit none
type(integrator_t) :: integrator
integrator = integrator_t::fixed_step(fixed_step_integrator_t(0.5_dp))
call solve(integrator)
write(*,*) ''
integrator = integrator_t::variable_step(variable_step_integrator_t(1.0_dp, 0.1_dp))
call solve(solver)
end program
which would output:
Solving equations with fixed step solver
stepsize: 0.5
Solving equations with variable step solver
min stepsize: 1.0
tolerance: 0.1
The syntax in this example isn’t very well thought out, but I hope it could highlight the potential that lies in “functional style” enums as opposed to “C style” enums.
Here is an update from @sblionel, the convenor: It’s Getting Drafty in Here.
…
The timeframe for this process is expected to conclude in early 2023, so I have proposed that we call this new revision Fortran 2023 as its informal name. Formally, it will be ISO/IEC 1539-2023. As John Reid points out in his document, this is another “small revision” which, while it has a lot of useful new features, doesn’t have any “really big” ones. In particular, while we had hoped to be able to put generic programming into Fortran 202X, it wasn’t ready in time, and we’ve deferred it to the next revision that we’re calling Fortran 202Y.We did, however, start work on generics and have made a good head start on it, so it seems probable that it will get done for 202Y. There are many other ideas already being explored; a good place to see what people have suggested, or to suggest your own, is a Github repository called Fortran Proposals. Check it out!
Another place to discuss generics is GitHub - j3-fortran/generics .
4 Likes
I’ve been waiting for the API to finalize before revisiting this. The previous version had three different forms of split. The finalized API has one form of split and two forms of tokenize (better!). I expect to work on this in the next month or so.
1 Like
For the first time, the committee draft dated from the 2022-04-22 uses the name “Fortran 2023” instead of 202x:
https://j3-fortran.org/doc/year/22
3 Likes