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]

I will observe that it is in any vendor's best interest to not set expectations for future development timeframes. Do recognize that Intel has been one of the first vendors to fully support new standards over the last few revisions, and I don't expect that to change. 

[andrew_4619]

LOL. My expectations of speed or indeed a definitive answer are indeed low however it doesn't hurt to ask! 

[Barbara_P_Intel]

I keep this article up to date with Fortran and OpenMP standards features that are implemented in each ifx release. There are some F2023 features in ifx 2024.0.0.

It looks like there's more to come in the next release, 2024.1.0.

[FortranFan]

---

@Barbara_P_Intel wrote:

I keep this article up to date with Fortran and OpenMP standards features that are implemented in each ifx release. There are some F2023 features in ifx 2024.0.0.

It looks like there's more to come in the next release, 2024.1.0.

---

Thank you very much @Barbara_P_Intel .

Your article mentions among the Fortran 2023 implemented in version 2024:

• "BOZ constants as INTEGER values in ENUMERATION statements"

Will it be please possible for you and/or Intel Fortran team to provide a small working example of this facility as *supported* by Intel Fortran 2024.0?  Thank you,

[andrew_4619]

The BOZ constants support  is a little confusing. This usage of BOZ has been permitted in intel Fortran   for a considerable time as an Intel extension but would generate a standards error if you has that check on.  It still generates a standards error because there is no 2023 standards checking option.

[Steve_Lionel]

Right - the BOZ enhancements in F2023 standardize existing practice in most compilers, though some did things a bit differently.  For some background, see j3-fortran.org/doc/year/19/19-212r1.txt , j3-fortran.org/doc/year/19/19-256r2.txt , and j3-fortran.org/doc/year/21/21-101.txt (alternative 2 was passed).

[Ron_Green]

We have a bug/feature request for changing the warning for BOZ enhancements, based on the new Standard.  Based on your request I bumped that up on our priority list.  It's actually a fair amount of work in the front front-end.  One of those that sounds simple but actually touches a lot of code.

As for the roll out of F23 - we will be adding these in a little at a time.  Our top priority for the first 8 months of 2024 is to clean out the backlog of your issues submitted to us that we had to put on hold while we were developing ifx.  You have probably seen us posting 'This is fixed in the current release' or 'We have it fixed in the next update'.  We are aggressively going after these issues from our users.  Hopefully we can clear out a lot of this backlog for the 2025.0 release.

[Barbara_P_Intel]

@FortranFan, since you asked for an example of “BOZ constants as INTEGER values in ENUMERATION statements”, here it is:

ENUMERATION :: RED=0’10’

I relied on my friends who speak "standard" better than I do for this.

Note: this is the interoperable ENUM type, not the Fortran 2023 enumerators (yes, there are two types now) as those have not yet been implemented.

This sample will be in the 2024.1 version of the DGR.

I've also been assured that the "green" documentation that means this feature is Intel only, will be "black" for those features that are now in F2023.

[FortranFan]

---

@Barbara_P_Intel wrote:

.. here it is:

ENUMERATION :: RED=0’10’

I relied on my friends who speak "standard" better than I do for this.

Note: this is the interoperable ENUM type..

---

Thank you very much @Barbara_P_Intel .

I suggest you loop back with 'friends who speak 'standard"' and request them to recheck against the standard.

What they informed you appears non-conforming.

What you show is exactly what I was expecting and which, per the Fortran 2023 document (or at least a proxy for it in 23-0071r1), does not appear to be supported.  Your  'friends who speak 'standard"' may want to keep this example in mind:

! Updated facility per Fortran 2023
module m
   enum, bind(C) :: foo_e
      enumerator :: e1 = 2 !<-- Ok, conforming
      enumerator :: e2 = int( O'4' ) !<-- Ok, conforming, BOZ using INT intrinsic
      enumerator :: e3 = O'10'  !<-- NOT Ok, non-conforming, BOZ not allowed directly
   end enum                      ! 
end module
! Usage
   use m, only : foo_e, e1, e2, e3  !<-- REALLY!!!
   type(foo_e) :: a, b, c, d, e
   a = e1 !<-- Ok, conforming, assignment using enumerator
   b = foo_e( 2 )  !<-- Ok, conforming, using enum constructor
   c = foo_e( O'4' ) !<-- Ok, conforming, using enum constructor
   d = 8 !<-- NOT Ok, non-conforming, an integer-expression on RHS
   e = O'10' !<-- NOT Ok, non-conforming, an integer-expression on RHS
end

[jimdempseyatthecove]

FF, are you saying an octal literal doesn't have an implicit type of integer (when used as an initializer)?

    integer :: e3 = O'10' ! no error expected here

Jim Dempsey

[FortranFan]

@jimdempseyatthecove ,

Note per the Fortran 2023 standard,

---

29 C7119 (R772) A boz-literal-constant shall appear only as a data-stmt-constant in a DATA statement, as the
30              initialization for a named constant or variable of type integer or real, as the expr in an intrinsic assignment
31              whose variable is of type integer or real, as an ac-value in an array constructor with a type-spec that
32              specifies type integer or real, as the scalar-expr in an enum constructor, or where explicitly allowed in
33              16.9 as an actual argument of an intrinsic procedure.

---

Thus, note a "boz-literal-constant" is not a scalar-int-constant-expr whereas the interoperable enum type declaration, per the standard, only permits a scalar-int-constant-expr.  The BNF for the interoperable enum type declaration is

12 R759 enum-def is enum-def-stmt
13                                          enumerator-def-stmt
14                                          [ enumerator-def-stmt ] ...
15                                   end-enum-stmt
16 R760 enum-def-stmt             is ENUM, BIND(C) [ :: enum-type-name ]
17 R761 enumerator-def-stmt  is ENUMERATOR [ :: ] enumerator-list
18 R762 enumerator                    is named-constant [ = scalar-int-constant-expr ]
19 R763 end-enum-stmt             is END ENUM

---

So here, note R762, "enumerator is named-constant [ = scalar-int-constant-expr ]"

TL;DR:

• 'ENUMERATION :: RED=0’10’', as communicated to @Barbara_P_Intel by her friends who can speak 'standard', does not conform with Fortran 2023.

[Steve_Lionel]

@FortranFan wrote: "enumerator :: e3 = O'10' !<-- NOT Ok, non-conforming, BOZ not allowed directly"

I believe that statement is conforming, but it may not be immediately obvious. Quoting 23-007r1 (emphasis mine):

"C7119 (R772) A boz-literal-constant shall appear only as a data-stmt-constant in a DATA statement, as the initialization for a named constant or variable of type integer or real," 7.7

"An interoperable enumerator is a named integer constant." 7.6.1

BOZ constants have no type. As of F23, they can be used in selected contexts where the type is assumed from context, something many compilers have allowed for decades.

Further reading: Doctor Fortran in "We're All BOZos on This Bus" - Doctor Fortran (stevelionel.com)

[Steve_Lionel]

Reply deleted - see next reply (once I enter it).

[Steve_Lionel]

I think there's a missing edit and will ask about this. Consider the difference between the syntax rule for the PARAMETER statement and ENUMERATOR. For PARAMETER, we have:

R854 parameter-stmt is PARAMETER ( named-constant-def-list )
R855 named-constant-def is named-constant = constant-expr

If you chase constant-expr, you end up at R605 for literal-constant where a boz-literal-constant is allowed.

But for ENUMERATOR we have, as @FortranFan cites:

R762 enumerator is named-constant [ = scalar-int-constant-expr ]

and a BOZ constant is not an int-constant-expr.

PARAMETER seems to be OK, but it took some digging to decide this.

The intent was that this should be conforming.

[Steve_Lionel]

Malcolm agrees that there are missing edits, and I will draft an interpretation request about it.

[andrew_4619]

Well this thread got interesting and a tad complicated!

[Steve_Lionel]

Interpretation request submitted: j3-fortran.org/doc/year/24/24-101.txt

[Barbara_P_Intel]

As a follow up, my friend who can speak 'standard' wrote, "Another indication that it was intended to allow BOZ constants as initializers for interoperable ENUMs is constraint C7113.

                R765     enum-constructor            is             enum-type-spec ( scalar-expr )  

                C7113 The scalar-expr in an enum-constructor shall be of type integer or be a boz-literal-constant.

So, there is evidence that it was intended for BOZ constants to be used to initialize interoperable ENUMs, as they are allowed in ENUM constructors.  It would be very strange to allow them there, but not in the declaration of the ENUMERATOR."

[FortranFan]

---

@Barbara_P_Intel wrote:

As a follow up, my friend who can speak 'standard' wrote, "Another indication that it was intended to allow BOZ constants as initializers for interoperable ENUMs is constraint C7113.

                R765     enum-constructor            is             enum-type-spec ( scalar-expr )  

                C7113 The scalar-expr in an enum-constructor shall be of type integer or be a boz-literal-constant.

So, there is evidence that it was intended for BOZ constants to be used to initialize interoperable ENUMs, as they are allowed in ENUM constructors.  It would be very strange to allow them there, but not in the declaration of the ENUMERATOR."

---

I can assure the readers of this forum and the customers of Intel this was NO "oversight" in the standard.

I won't state anything further on this until around mid-March 2024.

I do hope against hope the "comedy of errors" that is about to transpire on this will ultimately be in FAVOR of the poor, persevering practitioners of Fortran and thus EXCLUDE them from the "BOZOs on this bus."

[Steve_Lionel]

Yes - this was just an oversight. It happens more often than we'd like. Of course, it is found just AFTER we publish the new standard!