# Fortran 2023 standard **URL:** \ **Category:** Help\ **Created:** [February 5, 2023, 9:42pm UTC](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137 "2023-02-05T21:42:09Z")\ **Posts on this page:** 20\ **Page:** 7
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [July 12, 2023, 3:25pm UTC](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137/132 "2023-07-12T15:25:38Z")
> [@RonShepard](#): > > … How do you propose to access the original data in a way that allows a compiler to avoid that extra effort? … Can you please list the contexts you have in mind when it comes to accessing the character data of a `string` type? That will help clarify. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [July 12, 2023, 4:56pm UTC](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137/133 "2023-07-12T16:56:52Z")
For use in an expression, as a subroutine argument, on the left hand side of a character expression, in a pointer assignment, etc. In addition to the efficiency aspect, there are many situations where you want to access the data itself, not a copy of the data. ---
**Author:** ![sblionel](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/sblionel/32/853_2.png) [@sblionel](https://fortran-lang.discourse.group/u/sblionel)\ **Post date:** [August 8, 2023, 2:20pm UTC](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137/134 "2023-08-08T14:20:48Z")
Sticking this here, as good a place as any… The F2023 FDIS went out for ballot on August 3. According to the ISO Project page, close of voting is September 28. Assuming there are no disqualifying objections, publication should occur in October. The ISO Editor has asked for some minor boilerplate changes before publication, which should not hold things up. So close! Looking to the future, WG5 is joining an effort by the C and C++ projects to request that ISO allow paragraph numbers in programming language standards, so that we don’t have to request exemptions each time. We did not make that request for F2023, so the published standard will not have paragraph numbers. Our “interpretation document”, which the committee uses internally, will continue to have both paragraph and line numbers. ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [August 8, 2023, 2:40pm UTC](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137/135 "2023-08-08T14:40:22Z")
Congratulations. Thanks for the update and for serving as convenor. ---
**Author:** ![sblionel](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/sblionel/32/853_2.png) [@sblionel](https://fortran-lang.discourse.group/u/sblionel)\ **Post date:** [September 30, 2023, 6:35pm UTC](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137/136 "2023-09-30T18:35:33Z")
Balloting on the F2023 FDIS closed yesterday. There were 16 member bodies that voted (14 P-members and 2 O-members). All voted to approve. What’s left is some boilerplate cleanup, and the standard should be published sometime in October or maybe early November. ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [November 18, 2023, 9:42am UTC](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137/137 "2023-11-18T09:42:17Z")
This page [WG5 Fortran - Fortran 2023](https://wg5-fortran.org/f2023.html) still says “Fortran 2018 is the current standard.” But the ISO website tells another story 🍾 : > **[ISO/IEC 1539-1:2023](https://www.iso.org/standard/82170.html)** > > Programming languages — Fortran — Part 1: Base language > General information > > - Status: Published > Publication date: 2023-11 > Stage: International Standard published [[60.60](https://www.iso.org/standard/82170.html#lifecycle)] > - Edition: 5 > Number of pages: 674 > - Technical Committee : [ISO/IEC JTC 1/SC 22](https://www.iso.org/committee/45202.html) > ICS : [35.060](https://www.iso.org/ics/35.060.html) It happened yesterday, the 17th November. ---
**Author:** ![sblionel](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/sblionel/32/853_2.png) [@sblionel](https://fortran-lang.discourse.group/u/sblionel)\ **Post date:** [November 18, 2023, 12:37pm UTC](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137/138 "2023-11-18T12:37:47Z")
Wonderful news - I didn’t receive notice of this. ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [November 19, 2023, 7:47pm UTC](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137/139 "2023-11-19T19:47:29Z")
Other languages having a new ISO standard in 2023 are (from the oldest to the youngest): - [ISO/IEC 1989:2023 - Information technology — Programming languages, their environments and system software interfaces — Programming language COBOL](https://www.iso.org/standard/74527.html) - [ISO/IEC 9075-1:2023 - Information technology — Database languages SQL — Part 1: Framework (SQL/Framework)](https://www.iso.org/standard/76583.html) - [ISO/IEC 8652:2023 - Information technology — Programming languages — Ada](https://www.iso.org/standard/83621.html) - [ISO/IEC 20619:2023 - Information technology — C# specification suite](https://www.iso.org/standard/86347.html) ---
**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:** [November 22, 2023, 12:19am UTC](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137/140 "2023-11-22T00:19:54Z")
People love Fortran. > ---
**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:** [November 23, 2023, 7:33pm UTC](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137/141 "2023-11-23T19:33:48Z")
This was our most successful tweet to date. It reached over 130K people and we got close to 300 (~10%) new followers in two days. Happy Thanksgiving, all. ---
**Author:** ![msz59](https://avatars.discourse-cdn.com/v4/letter/m/3d9bf3/32.png) [@msz59](https://fortran-lang.discourse.group/u/msz59)\ **Post date:** [November 26, 2023, 7:31pm UTC](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137/142 "2023-11-26T19:31:12Z")
Are you aware of any of the _new features_ already supported (as an extension) in any of renowned compilers? ---
**Author:** ![Shahid](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/shahid/32/3672_2.png) [@Shahid](https://fortran-lang.discourse.group/u/Shahid)\ **Post date:** [November 26, 2023, 8:10pm UTC](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137/143 "2023-11-26T20:10:16Z")
[https://www.intel.com/content/www/us/en/developer/articles/technical/fortran-language-and-openmp-features-in-ifx.html](https://www.intel.com/content/www/us/en/developer/articles/technical/fortran-language-and-openmp-features-in-ifx.html) These features from Fortran 2023 are implemented. - The REDUCE locality spec on DO CONCURRENT - BOZ constants on RHS of INTEGER and REAL assignment statements - BOZ constants as INTEGER and REAL values in PARAMETER statements - BOZ constants as INTEGER or REAL as array constructor values - BOZ constants as INTEGER values in ENUMERATION statements - Intrinsic trigonometric functions returning degrees ACOSD(X), ASIND(X), ATAND(X), ATAN2D(Y, X), COSD(X), SIND(X), and TAND(X) ---
**Author:** ![msz59](https://avatars.discourse-cdn.com/v4/letter/m/3d9bf3/32.png) [@msz59](https://fortran-lang.discourse.group/u/msz59)\ **Post date:** [November 26, 2023, 8:27pm UTC](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137/144 "2023-11-26T20:27:31Z")
> [@RonShepard](#): > > > [@FortranFan](#): > > > > Now imagine a practitioner proposing the same: she will virtually be yelled at and insulted no differently than the “no soup for you” as in the skit with the added quip about Fortran already having the short-form `a( :, : )` and `real, dimension( :, : ) :: a` options, and thus there being no need nor any use for anything with an integer constant with a `RANK` attribute. > > Yes, that is the obvious objection to this feature. If the `RANK()` argument were allowed to be a variable, then that would have been added functionality to the language, e.g. towards generic programming with arguments of arbitrary rank. But as specified, it appears to be simply syntax sugar for functionality that already exists in the language. > > Am I missing something here? If I correctly read the 23-007r1 Draft description of `ALLOCATE` modified syntax, incl. R933/937/939, the following should be doable in F2023: ```fortran integer, parameter :: r=3, size=5 real, rank(r), allocatable :: tab ... allocate(tab([(size,i=1,r)])) ``` to allocate a _rank_-`r` array with parametrized rank. Changing the rank requires just one modification. That could be hardly achieved with _colon_ syntax. Surely probably any real processing of such arrays would still require to pass them as _assumed-rank_ object to a procedure and there using `select rank` construct. So it is just a small step forward. ---
**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\ **Post date:** [December 20, 2023, 6:11pm UTC](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137/145 "2023-12-20T18:11:41Z")
The new optional `lower` argument of the `c_f_pointer` intrinsic, allows one to implement a very cryptic `impure` integer addition function, ```fortran function iadd(a, b) result(c) use, intrinsic :: iso_c_binding integer, value :: a, b integer :: c character(c_char), pointer :: t(:) call c_f_pointer(c_null_ptr, t, shape=[a+1],lower=[0]) call c_f_pointer(c_loc(t(a)), t, shape=[b+1],lower=[0]) c = transfer(c_loc(t(b)), iadd) end function ``` that in some odd sense, mimics what the x86 hardware is doing with the [LEA instruction](https://www.felixcloutier.com/x86/lea) (see below). Note, I haven’t tested the routine above since I’m not sure any compiler supports `lower` yet. (I’m aware I’m using `+1` to get the shape, but didn’t want to complicate this any further. On a two’s complement machine, you can add 1 using `-not(i)`.) ```fortran pure function plus(a,b) result(c) integer, value :: a, b integer :: c c = a + b end function ``` ```txt plus_: lea eax, [rdi+rsi] ret ``` According to the [System V](https://wiki.osdev.org/System_V_ABI#x86-64) calling conventions, `eax` serves as the result register (`c`), and `rdi` and `rsi` are the registers of the first two arguments (`a` and `b` in this case). I took the idea from the following C code found on [Stack Overflow](https://stackoverflow.com/a/366247/4283055), ```cpp int add(int a, int b) { const char *c = 0; return &(&c[a])[b]; } ``` (Don’t use this code, it’s just a silly example to demonstrate some addressing concepts.) ---
**Author:** ![Harper](https://avatars.discourse-cdn.com/v4/letter/h/b5ac83/32.png) [@Harper](https://fortran-lang.discourse.group/u/Harper)\ **Post date:** [December 20, 2023, 8:14pm UTC](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137/146 "2023-12-20T20:14:18Z")
What would @ivanpribec’s iadd function do if a+b would overflow? ---
**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\ **Post date:** [December 20, 2023, 10:34pm UTC](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137/147 "2023-12-20T22:34:58Z")
A few resources I consulted state the `lea` instruction does not set any [condition codes](https://en.wikipedia.org/wiki/FLAGS_register) (carry, overflow), meaning you cannot discern if the signed overflow or unsigned wraparound occurred. In practice I observe signed overflow occurs: ```c #include #include int add(int a, int b) { const char *c = 0; return (int) &(&c[a])[b]; } int main(void) { printf("c = %d\n", add(INT_MAX,0)); printf("c = %d\n", add(INT_MAX,1)); return 0; } ``` ```txt $ gcc-13 -Wall -Wno-pointer-to-int-cast -std=c99 -Os -fno-inline && ./a.out c = 2147483647 c = -2147483648 ``` According to the [gfortran documentation](https://gcc.gnu.org/onlinedocs/gfortran/Behavior-on-integer-overflow.htm), integer overflow is prohibited (in the sense the programmer guarantees it will not happen). So from this point of view a compiler can happily assume `c_loc(t(a))` will always return a valid valid address. Perhaps not for everyone, but there is an interesting talk on a related topic: [\*(char\*)0 = 0; - What Does the C++ Programmer Intend With This Code?](https://www.youtube.com/watch?v=dFIqNZ8VbRY) ---
**Author:** ![VladimirF](https://avatars.discourse-cdn.com/v4/letter/v/e9a140/32.png) [@VladimirF](https://fortran-lang.discourse.group/u/VladimirF)\ **Post date:** [December 21, 2023, 8:49am UTC](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137/148 "2023-12-21T08:49:02Z")
If I understand is correctly, the draft document is no longer available for Fortran 2023 from WG5. I found a version at J3 and some further changes in txt files, but it is somewhat unfortunate and can lead to problems when searching what is a compiler defect and what is the standard behaviour. ---
**Author:** ![sblionel](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/sblionel/32/853_2.png) [@sblionel](https://fortran-lang.discourse.group/u/sblionel)\ **Post date:** [December 21, 2023, 6:32pm UTC](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137/149 "2023-12-21T18:32:48Z")
There will be a new “Interpretation reference document” on the J3 site soon - I have a preliminary version, but Malcolm (Editor) gets to decide when it goes out. ISO is very protective of its copyrights, so the WG5 site doesn’t publish drafts (and hasn’t since I created it in 2017.) ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [December 21, 2023, 7:32pm UTC](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137/150 "2023-12-21T19:32:51Z")
What is the difference between the “Interpretation reference document” and the latest draft? ---
**Author:** ![sblionel](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/sblionel/32/853_2.png) [@sblionel](https://fortran-lang.discourse.group/u/sblionel)\ **Post date:** [December 21, 2023, 8:09pm UTC](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137/151 "2023-12-21T20:09:05Z")
If by “latest draft” you mean 23-007r1, that is close to the published standard, with the addition of paragraph and line numbers, but there were some changes made based on ballot comments and some typo corrections. “Interpretation reference document”, such as 18-007r1 for F2018, is what the committee uses as a reference, and includes paragraph and line numbers. I don’t know anyone on the committee who buys the ISO printed version. I expect that the one for F2023 will be called 24-007. [Previous page](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137.md?page=6) [Next page](https://fortran-lang.discourse.group/t/fortran-2023-standard/5137.md?page=8)