Flang compiler implementation uses F2018 rules (and constraint) numbers in comments and docs with the corresponding code. The F2023 standard has reassigned some of these rule numbers to new features and renumbered existing features. For eg.
As we work towards adding the new F202X features, this will cause conflicts and confusion.
Renumbering existing comments is impractical - it will require a chain of comment edits and still be unclear what standard a rule corresponds to.
Is there an existing guideline regarding this issue?
If not, I would like to propose that any mentions of a rule (or constraint) number related to a F202X feature be qualified with the standard version for eg. F2023:R1526. Existing rule numbers, without the standard prefixed, would by default correspond to F2018.
They’re requirements, not rules. We’ve been using F’2023 before citations of subclauses, requirements, and constraints since it was published. I agree that older comments should be left alone.
After reviewing the Fortran standard published document, specifically J3/25-007r1 (Fortran 2028 Working Draft), chapter 4 Notation, conformance, and compatibility, section 4.1.1 Syntax rules mentions:
1 Syntax rules describe the forms that Fortran lexical tokens, statements, and constructs may take. These 5 syntax rules are expressed in a variation of Backus-Naur form (BNF) with the following conventions.
This to me implies that the word “rule” and not “requirement” is the correct one when referring to the Fortran grammar.
While I understand that the word “requirement” is preferred by some members of the community, I would like to use the official language.
This topic was discussed in the Flang community call on 2026-03-25 ( Combined Flang Community Call Notes - Google Docs ). The consensus was that this is reasonable and it’s a good idea to add it to the coding standards document. I will shortly put up a PR to update the document.
Want to post the comment here to give it more visibility. The current proposal for referring to Fortran spec things this: F2023 9.7.3.2 p7 (Fortran 2023, section 9.7.3.2, paragraph 7), F2023 R1526 (Fortran 2023, rule R1526). This deviates a bit from current practice of using apostrophe, e.g. F’2023 …. Personally, I’m in favor of dropping the apostrophe, less things to type.
Those who have commit privileges and agree with this, I would appreciate if you could go to the PR and approve it. Those who strongly disagree with this, let’s discuss here, so it gets visibility.
We also name our files and folders that have the version number without a separator, eg. F202X.md, f2018-grammar.md or folder names in testsuite repo cray/f2023, etc. Dropping the apostrophe and just using F can be a standard throughout the codebase going forward.
