F2023 roadmap

[andrew_4619]

I was wondering if Intel has a road map of F2023 implementation and what features we may see in 2024. I particularly like the  new conditional expressions and arguments options which  makes for more concise coding.  There is some explanation of these features at the DR Fortran blog. https://stevelionel.com/drfortran/2023/11/23/fortran-2023-has-been-published/

[Steve_Lionel]

It absolutely was an oversight, and to suggest otherwise is offensive. This event does illustrate my frequent observation that there are no zero-cost features - even something already supported by many compilers. Finding all the necessary places in the standard that need revision is complex and, especially for something like this where we know what we meant to say, mistakes do happen. That's the whole reason for the interpretation process.

[FortranFan]

---

@Steve_Lionel wrote:

It absolutely was an oversight, and to suggest otherwise is offensive..

---

This is absolute B.S.  Facts and truth may be bitter, but objectively they cannot be termed "offensive".

And the absolute truth is the omission of the support of BOZ literals with C interoperable ENUMs was NOT an oversight.  I had pointed out this omission via written (email) communication to the head of the /DATA subgroup in the "J3" committee that serves as a contractor to WG5 body for the Fortran standard with a CC to @Steve_Lionel .  This was during year 2020 when the world was in lockdown and the meetings were mostly over limited Zoom sessions.  I had repeatedly pleaded for this facility which I thought was a rather simple thing, a "no-brainer", and that the committee reps should **not** be making such a big deal out of this but yet they did.

From the rude responses I received to my plea, the only thing I could gather at the time was a certain sloth or reluctance to go the extra "yard" for Fortranners, because you see the C standard effectively permits a conforming processor to "read in" all the values of the enumerators before deciding on the type (more like kind in Fortran parlance) of the enumeration.  The head of the /DATA subgroup didn't want this "complication" in the compiler implementation he works on, even though this is a great facility for the ordinary practitioners.

To understand this better, consider the following silly example:

#include <stdio.h>

void main( void ) {
   enum foo { foo };
   enum bar { bar=0x200000000 };
   printf("Size of foo: %zd\n", sizeof(foo));
   printf("Size of bar: %zd\n", sizeof(bar));
}

And the program response using GCC 15 (experimental):

C:\temp>gcc c.c -o c.exe

C:\temp>c.exe
Size of foo: 4
Size of bar: 8

C:\temp>

Notice how the processor has decided upon a 8-byte data type for "bar" versus 4-byte for "foo".  The processor decided upon this based on the values of the enumerators.  And this is permitted by the C standard.

Technically the Fortran standard should support the same and ensure the right kind of integer gets defined by the Fortran processor on the enumerators and the enumeration so that it will be consistent with the companion C processor.

It is great @Steve_Lionel has a paper (j3-fortran.org/doc/year/24/24-101.txt) at the ongoing J3 meeting in Berkeley, California.   It will be interesting to see as to how it goes with the committee this time, whether they will be alert as to this complication or not, or the past indolence is now cured post-covid!  

And it is "Duh!" that there is no such thing as "zero-cost" feature, obviously everything takes some time and effort and therefore incurs cost.  But the entire premise starting with abacus and slide rule to computers and Backus and team with IBM FORTRAN is for the device/processor to assume that little bit of "cost" so that the users gain immeasurable benefits from the implementation.  It is an utter shame some influential members on the Fortran committee seek to constantly overlook or misdirect the users from this premise.  Truly this attempt is what is "offensive", it is treating the practitioners of Fortran as BOZOs on a bus, to the borrow from the title of a blog.

Anyways, "fingers crossed" on the paper at the J3 meeting, hopefully it will pass!

[Steve_Lionel]

Interp request 24-101 was taken up today - we didn't get to it in February. Interp subgroup head Malcolm Cohen introduced it, saying that this was an oversight, which is supported by the text of work item US23, that says:

Requirements (from 19-212r1):
-----------------------------

Allow the following usage of BOZ constants beyond what is allowed in
C7109, as follows:

A: BOZ as an initialization in the definition of an integer named
constant.

The standard, in 7.6.1 Interoperable enumerations and enum types, says, "An interoperable enumerator is a named integer constant". It was an oversight that we missed this additional category of named integer constants for allowing BOZ constants, when constructing the edits for the feature.

@FortranFan , I am not privy to any correspondence you may have had with Malcolm, who is also the head of the Data subgroup, but if it resembled your posts here, I would not be astonished if his reply took a similar tone; he is not as patient nor forgiving as I am. 

We did find an additional missed edit and added that to the paper. It passed unanimously - the updated paper is 24-101r1.

You brought up a somewhat unrelated topic, which if I understand correctly, is about which kind of integer should be used for the enumeration. Fortran follows C18, where enumerators are int. It does appear that C23 expanded this, but Fortran doesn't follow that. (I don't have a copy of the C standard, so I may have missed something, but I did find some good discussions online of C enumerations that talked about this.) Nevertheless, it is something we'll need to consider for the next revision.