The post at https://groups.google.com/g/comp.lang.fortran/c/DOC-CNFy3A4 describing some new features of Fortran 202X is interesting.
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):
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).
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
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.
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
Nice, that means I might still be alive when compilers for common mortals actually support the new features.
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=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
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.
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 .
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.