On backward compatibility

[FortranFan]

Backward compatibility, or not to break existing code, is often put forth as the argument against many a proposal, this issue #40 is a classic instance of this. This issue #72 is also seeing a similar debate.

However there appear to be 2 major issues with this argument:

1. it is very difficult, almost impossible, to find an objective analysis of the risks due to a change. If a breaking change is only a theoretical possibility but if most or all the publicly known codebases are not noticed to be at risk due to the change, how valid is the argument then to not consider an idea?

2. on the other hand, there exist quite a few instances in the standard where compatibility with an earlier revision has been dropped for some aspect or other, often presented as different interpretations but they also include features which are DELETED such as from FORTRAN 77 and earlier editions.

Consider the current Fortran 2018 standard: with respect to Fortran 2008 itself, one can argue changes have been incorporated that break existing code, at least under the theoretical possibility of conforming processors offering support for the prior interpretation. With object-oriented facilities in Fortran, my codes have had to deal with "breaking changes" in going from processors supporting Fortran 2003 thru' 2018.

20 4.3.3 Fortran 2008 compatibility
21 1  Except as identified in this subclause, and except for the deleted features noted in Annex B.2, this document is
22    an upward compatible extension to the preceding Fortran International Standard, ISO/IEC 1539-1:2010 (Fortran
23    2008). Any standard-conforming Fortran 2008 program that does not use any deleted features, and does not use
24    any feature identified in this subclause as being no longer permitted, remains standard-conforming under this
25    document.
26 2  Fortran 2008 specifies that the IOSTAT= variable shall be set to a processor-dependent negative value if the flush
27    operation is not supported for the unit specified. This document specifies that the processor-dependent negative
28    integer value shall be different from the named constants IOSTAT_EOR or IOSTAT_END from the intrinsic
29    module ISO_FORTRAN_ENV.
30 3  Fortran 2008 permitted a noncontiguous array that was supplied as an actual argument corresponding to a
31    contiguous INTENT (INOUT) dummy argument in one iteration of a DO CONCURRENT construct, without
32    being previously defined in that iteration, to be defined in another iteration; this document does not permit this.
   4  Fortran 2008 permitted
1     a pure statement function to reference a volatile variable, and permitted a local variable
2     of a pure subprogram or of a BLOCK construct within a pure subprogram to be volatile (provided it was not
3     used); this document does not permit that.
4 5   Fortran 2008 permitted a pure function to have a result that has a polymorphic allocatable ultimate component;
5     this document does not permit that.
6 6   Fortran 2008 permitted a PROTECTED TARGET variable accessed by use association to be used as an initial7
      data-target; this document does not permit that.
8 7   Fortran 2008 permitted a named constant to have declared type LOCK_TYPE, or have a noncoarray potential
9     subobject component with declared type LOCK_TYPE; this document does not permit that.
10 8  Fortran 2008 permitted a polymorphic object to be finalized within a DO CONCURRENT construct; this docu11
      ment does not permit that.
12 9  Fortran 2008 permitted an unallocated allocatable coarray or coindexed object to be allocated by an assignment
13    statement, provided it was scalar, nonpolymorphic, and had no deferred type parameters; this document does
14    not permit that.
15 10 Fortran 2008 permitted the processor to use a common pseudorandom number generator for all images. This
16    document requires separate seeds on each image for the pseudorandom number generator.

So what it appears to me is an inconsistency in how the "backward compatibility" argument is applied and perhaps even an inaccuracy in the argument "oh, that will break existing code and that is a no-no" that is put forth.

It'll be valuable for Fortran if a technical approach to address the bugaboo of backward compatibility can be adopted.

One aspect of such an approach might involve the establishment of a "registry" of Fortran codebases: such a registry only need to have links to existing projects online such as GitHub, SourceForge, etc. or to institutional sites e.g., DOE, NASA, NOAA, academia, etc., or simply be entries which provide a brief description of what code does and the coding styles adopted per true intent e.g., the use of IMPLICIT typing (as opposed IMPLICIT NONE), or IMPLICIT SAVE, data types, and so forth. This can a "green" registry of course, meaning it should grow as new applications are developed using Fortran.

Then when a proposal is presented, one can crosscheck it against such a registry for impact analysis (and where possible like with GitHub or online repositories with a code review) to yield a somewhat quantitative assessment of the risk due to the change; this is as opposed to someone's 'gut feel' at present which might be overestimating the adverse impact of a proposal.

[sblionel]

As a former vendor, I can say with authority that paying customers blame the vendor when their existing code breaks due to a change. Rather than fix their code, they want a switch to revert to the old behavior. If the existing code was non-conforming, I have little sympathy, but the cases where a standard change breaks code are rare. Most of the cases mentioned in the text you quote are where the earlier standard was silent about some combination of uses. Changing the kind that an intrinsic returns, as has been suggested in #72 , would break code that used these intrinsics as actual arguments.

Registry of code libraries is a non-starter. Keep in mind that the usages you see are like the part of an iceberg above water - the vast majority of code is kept privately by organizations loathe to make changes.

Whether you like it or not, a major strength of Fortran is that, by and large, standard revisions have not broken existing code bases, allowing the vast extent of code libraries to continue to be used.

[certik]

Thanks @FortranFan for opening an issue for this. Thanks @sblionel for your comment. I agree with it.

What we can do is to write up what we mean by "backwards compatibility" in some document here in the repository, so that new proposals can check against it that they are not breaking it.

[gronki]

I guess here we go back to the idea of Fortran testsuite #57 (although huge organizational effort and workforce needed to construct) where most usual applications and usage patterns for constructs can be used, and whatever breaks it is considered backwards incompatible. As I said in another thread, the example of "using as actual argument" given by @sblionel is quite fair and I agree with it. Using size(x) as an actual argument is not an inherently bad coding practice. But I can also totally see how some other good and highly beneficial proposition could be rejected just because somebody found one exotic combination of common blocks, namelists and equivalences that standard permitted even if it was objectively bad programming and affected only one code. Are "losses vs benefits" weighted in that case?

Are obsolescent features still the subject of backwards compatibility considerations? I understand that deleted features are not?

wt., 12 lis 2019 o 18:58 Ondřej Čertík notifications@github.com napisał(a):

Thanks @FortranFan https://github.com/FortranFan for opening an issue for this. Thanks @sblionel https://github.com/sblionel for your comment. I agree with it.

What we can do is to write up what we mean by "backwards compatibility" in some document here in the repository, so that new proposals can check against it that they are not breaking it.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/j3-fortran/fortran_proposals/issues/79?email_source=notifications&email_token=AC4NA3K3CMTCGGKJ7IAEJPLQTLVEBA5CNFSM4JMGYGLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOED3FKBA#issuecomment-553014532, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC4NA3LW7UT7YUX5L3XOQTLQTLVEBANCNFSM4JMGYGLA .

[klausler]

Older codes should compile and execute without change with newer compilers, possibly implementing new editions of a language standard, everything else being equal. That latter part is important. Sometimes target architectures differ from each other or evolve in place in ways that require some porting of codes. In those situations, compilers (especially from hardware vendors) are going to want to ease the porting, and the standard should assist both coders and implementors with features that maximize and maintain portability.

Here's a specific example. Let's say that Big DOE Lab has a code that runs great on 32-bit x86 systems. When recompiled with a new compiler for 32-bit x86, it should just work, everything else being equal. And maybe that's enough for that code & customer. When recompiled for 64-bit x86 targets, if that's desired, it'll probably need some porting so that the larger address space can be exploited to serve larger sets of data. What features make that porting effort easiest on the customer? That's the question that should be driving the designs and standards.

[FortranFan]

See this observation re: implied SAVE: https://github.com/j3-fortran/fortran_proposals/issues/40#issuecomment-553164571.

So as brought up by @gronki , how are the pros of a change to be weighed against the cons which favor status quo on an issue?

[FortranFan]

83 suggests a new keyword to work around certain issues pertaining to backward compatibility.

[FortranFan]

Implicit typing (#90) can impact a new facility in a subtle way - see https://github.com/j3-fortran/fortran_proposals/issues/57#issuecomment-578310713. Processors can get the details wrong which negatively impact users in terms of time and lost productivity or worse. And many a user does find the whole notion with implicit typing in Fortran very confusing which further affects the adoption of the language.

Modern programming languages try to be rigorously type-safe and/or dynamically-typed. But implicit typing is something almost all of them avoid. But Fortran can choose to ignore the gathering wisdom of modern practitioners and continue to supporting IMPLICIT statements where, users can use such a facility to introduce implicit typing in their scopes and be responsible for their actions.

But what is pernicious is the continued support for implicit typing in Fortran as the **default**.

Then to expect any and all users to circumvent such a default only by introducing "IMPLICIT NONE" in all their scopes is truly "cruel and unusual punishment". It's one aspect that this language needs to shed - pronto.

[everythingfunctional]

I believe that while backwards compatibility is desirable in language development, it should not be a primary value, and should not prevent truly useful features from being added to the language.

I believe a significant reason that people choose languages other than Fortran for new work, even in scientific and engineering applications, is because those other languages have features which enable one to write safer, more maintainable, easier to understand code with less effort. In fact, organizations are encouraged to keep their code bases more maintainable and ensure continuity of knowledge because of the occasional breaking changes that occur in those languages. It seems a lack of backwards compatibility can actually be a virtuous cycle keeping your users in a better position.

I fear that Fortran's commitment to backwards compatibility at (practically) any cost has actually lead its users down a dangerous path to a precarious position. Eventually one of two things will happen:

1. It will no longer be possible to make changes to the language any more and it will die, forcing organizations to rewrite code that they no longer understand
2. A feature will come along that is worth breaking backwards compatibility, forcing organizations to fix code that they no longer understand

In my opinion, the sooner this happens the better, because it will only cost more the longer we wait. It's like continuing to spend on a credit card while only making the minimum payments. Eventually the introductory rate runs out or you hit your limit and you're really up a creek. Better to stop digging and take your lumps now.

[certik]

@FortranFan, @everythingfunctional it seems based on the feedback at this repository that the vast majority of the outside community agrees with your comments. When I talk to other Fortran developers, I do not see any strong opposition either to new features and even breaking features as long as old code does not just suddenly start breaking. In other words, as long as there is a path how to keep old code working without modifications, but new code can use breaking changes, it seems the community will be on board. Whether this is done with a new language keyword (#83) or some other way.

The best way forward is to have a serious discussion about this at the Committee meeting. And until then, @FortranFan, @everythingfunctional, do you want to help prepare some proposals for this? They do not have to be completely formal proposals that will get submitted, but it would help guide the discussion at the Committee if we have some documents in hand showing a way forward. It seems there are several ways, so it would be nice to have a document for #83, and another one for let's say the implicit save #40 with the implicit none(save) approach etc., and iron out the most obvious objections to such proposals, so that we can have a real discussion about the actual problem in person.

[tskeith]

@FortranFan, @everythingfunctional it seems based on the feedback at this repository that the vast majority of the outside community agrees with your comments. When I talk to other Fortran developers, I do not see any strong opposition either to new features and even breaking features as long as old code does not just suddenly start breaking. In other words, as long as there is a path how to keep old code working without modifications, but new code can use breaking changes, it seems the community will be on board.

I don't understand this. If old code works without modification, the changes aren't breaking (by definition).

Whether this is done with a new language keyword (#83) or some other way.

My understanding of the language keyword proposal is that it is a backward-compatible way to change default behavior.

[certik]

I don't understand this. If old code works without modification, the changes aren't breaking (by definition).

There are people on the Committee as well as some in the wider community that are opposed to this, as you can read in responses at #83 or #40. The reason they are opposed to it is that if you enable the modern feature (even if it is opt-in) for old code, the old code will break (for example if an implicit save now becomes implicit init). What I am saying is that I think the majority in the community would be ok with such a compromise (that unless you opt-in, the old code will keep working; but if you opt-in, then old code can break). The alternative (which I am suggesting we do not do) is that even if you opt-in, the old code will keep working (which is greatly tying our hands in what we can introduce into the language).

[everythingfunctional]

As @tskeith said, an opt-in requirement for new features is backwards compatible. I think that having new features be opt-in is the right approach in the near term, but it is still only a stop-gap measure. We need a long term strategy to eventually get to a point where the committee can at least entertain the idea of proposals that are not backwards compatible. Eventually we will need a change to the standard that will make old code no longer valid, and it shouldn't be DOA just because it's not backwards compatible.

Maybe we never get there and it will never be needed, but we should be heading in that direction. The whole point of software is being able to easily modify the behavior of the machine. If you can't change your software, it's already broken, whether you realize it or not. And the committee should stop enabling people to hide from it indefinitely.

[klausler]

What cannot happen is a silent change to the meaning of an unmodified existing program that works today.

[certik]

Eventually we will need a change to the standard that will make old code no longer valid

Can you give an example how exactly what that work? For example in the context of #83? Essentially the opt-in "edition" keyword would then become the default (with the latest edition), which would make old code to not work anymore? But one could put "edition F2003" into old code, and it would still work?

(Or are you proposing that there literally would be no way to make old code work at all? I think that would not be a good idea.)

[everythingfunctional]

My thought is the progression would go something like this:

• The version/edition keyword/option is introduced. This allows us to introduce non-backwards compatible features that are essentially "opt-in", but may render old code invalid or possibly change its behavior.
• At some point, compilers are no longer required to support older versions/editions in order to be considered standards compliant. And in fact, not specifying a version/edition would probably be an error (to prevent "silent" change to behavior).

At that point compilers aren't required to drop support, and you could of course continue to use older versions of compilers, but some old code would no longer be considered standards compliant.

So long as you give enough time, and are vocal and public about it, I don't see why this would be an unreasonable path.

[klausler]

Existing code must continue to work unchanged with new revisions of the standard and new versions of compilers unless there's extraordinarily compelling reasons; no serious examples of such have arisen in these discussions. Barring the introduction of zero-trip DO loops and the removal of extended ranges in FORTRAN '77, and the ephemeral CoCo, I can't think of any instances where the progress of the language has invalidated old code. Fortran 90 famously invalidated nothing (see section B-1 of that document).

[everythingfunctional]

@klausler , It's been asked plenty of times if it would be possible to remove implicit typing and implicit save from the language. I think they should, and so do many others. Maybe not for 202X, or even 202Y, but maybe by 203Z if you put edition 203Z at the top of your module, you won't need to put implicit none(type, save).

If we continue to treat that as a breaking change, and

Existing code must continue to work unchanged with new revisions of the standard and new versions of compilers

then it can never be done.

The "yeah, that'd be nice, but it breaks code written to the Fortran 77 standard so we won't even entertain it" is hindering progress and killing the language.

[klausler]

@klausler , It's been asked plenty of times if it would be possible to remove implicit typing and implicit save from the language. I think they should, and so do many others. Maybe not for 202X, or even 202Y, but maybe by 203Z if you put edition 203Z at the top of your module, you won't need to put implicit none(type, save).

If we continue to treat that as a breaking change, and

Existing code must continue to work unchanged with new revisions of the standard and new versions of compilers

then it can never be done.

If you are modifying a program to add a version marker, then it is no longer unchanged existing code.

The "yeah, that'd be nice, but it breaks code written to the Fortran 77 standard so we won't even entertain it" is hindering progress and killing the language.

Nonsense.

[certik]

@klausler please try to understand @everythingfunctional's point of view, even if you disagree with it. In particular, please try to explain your position instead of just saying "nonsense", in order to move the discussion forward.

[everythingfunctional]

If you are modifying a program to add a version marker, then it is no longer unchanged existing code.

Then I think we agree, and my proposed path forward would be acceptable to you, provided we never actually got to the point of dropping the requirement for supporting old standards, which I admit may never be necessary or desired.

But I have gotten the impression from mentions of old discussions that not everyone agrees with that stance. I got the feeling that some proposals were rejected in the past, even though they were opt-in, because "adding that one line changed the meaning of old code". Unless I'm mistaken, which I admit I may be, I don't think it is "Nonsense".

[certik]

@everythingfunctional let's talk about your proposal at https://github.com/j3-fortran/fortran_proposals/issues/79#issuecomment-578927520 some more. It seems it actually satisfies what @klausler wants.

For example, for current (old) code, if the version specifier is not specified, then the standard can say that it means the code implicitly assumes Fortran 202X. If you want to use features from a later Fortran standard (say 202Y), you have to put the version specifier in, such as "edition Fortran 202Y". However, the minute you put in "edition Fortran 202Y", it can break the code (say implicit save becomes implicit init).

This proposal has the following features:

1. Old code will continue working unmodified indefinitely.

2. If you put in "edition 202Y" then the old code will break, and it will have to be updated to work again. We should obviously try to provide automatic tools to update the code and excellent error messages to help update old code, good guidelines and we should only introduce breaking features that have a good "upgrade path" that can be done with big legacy codes. This would be file by file based, so it could be done incrementally.

3. Later on it can become an error not to specify the "edition" keyword. In that case, simply put "edition 202X" into old code and it will continue working umodified. Compilers can add an option such as "-legacy" that would assume "edition 202X". This point 3. might not be implemented in the standard. To me an acceptable solution would be that compilers would give warnings if "edition" is not specified, and you can turn off the warning with a compiler option.

[milancurcic]

I'm in favor of backward compatibility so I support points 1. and 2. here.

Point 3. is okay if not implemented in the standard, or if implemented as "the compiler should warn that edition is not specified".

In general, I think it's okay to consider new language-breaking features if the benefits clearly outweigh the costs. I haven't seen such proposals so far.

[klausler]

Version specifiers must not silently change the meaning of code. It's okay if they cause existing code to begin to elicit new error messages (e.g., they imply new checks akin to IMPLICIT NONE(SAVE)). But it would be dangerous to use versioning as a means for introducing silent changes to semantics. How would one know whether they occurred?

Requiring a version number to appear in the program at some point in the future would cause unmodified existing code to stop working.

[everythingfunctional]

@certik , I am in favor that, of course so long as there is nothing in 202X that would be "breaking", but I believe that has already been determined.

[klausler]

@klausler please try to understand @everythingfunctional's point of view, even if you disagree with it. In particular, please try to explain your position instead of just saying "nonsense", in order to move the discussion forward.

You should have seen the first draft of that word.

The claim that 'The "yeah, that'd be nice, but it breaks code written to the Fortran 77 standard so we won't even entertain it" is hindering progress and killing the language.' is hyperbolic and unsupported by evidence. The single example of a feature on this site that would have been a breaking change was a profoundly bad idea anyway (viz., allowing new enumeration names to stand alone as statements without keywords, so END would not necessarily be an END statement if somebody was declaring it as an enumerator).

[everythingfunctional]

Version specifiers must not silently change the meaning of code. It's okay if they cause existing code to begin to elicit new error messages (e.g., they imply new checks akin to IMPLICIT NONE(SAVE)).

I think this would forever require Fortran to carry around the baggage of its past mistakes. One would not be able to make a new proposal without first considering all of the possible implications to all prior versions of the language. Of course it wouldn't be a good idea to have silent changes between consecutive versions, but to never be able to change the meaning of old code?

But it would be dangerous to use versioning as a means for introducing silent changes to semantics. How would one know whether they occurred?

Your test suite I would expect. If we're never going to expect our users to start using modern software development practices, who are we modernizing the language for?

[klausler]

One would not be able to make a new proposal without first considering all of the possible implications to all prior versions of the language.

That is a good thing.

[everythingfunctional]

@klausler please try to understand @everythingfunctional's point of view, even if you disagree with it. In particular, please try to explain your position instead of just saying "nonsense", in order to move the discussion forward.

You should have seen the first draft of that word.

The claim that 'The "yeah, that'd be nice, but it breaks code written to the Fortran 77 standard so we won't even entertain it" is hindering progress and killing the language.' is hyperbolic and unsupported by evidence. The single example of a feature on this site that would have been a breaking change was a profoundly bad idea anyway (viz., allowing new enumeration names to stand alone as statements without keywords, so END would not necessarily be an END statement if somebody was declaring it as an enumerator).

There are multiple examples of breaking changes being proposed in this repo. Not the least of which are removing implicit typing and implicit save. And multiple mentions of backwards compatibility have been given as to why this wasn't done in the past or shouldn't be done now, even though they are regarded as the biggest mistakes of the language and the cause of the most confusion and error to new programmers. My statement may have been a bit hyperbolic, but it is not entirely "unsupported by evidence".

[everythingfunctional]

One would not be able to make a new proposal without first considering all of the possible implications to all prior versions of the language.

That is a good thing.

I disagree. There are multiple pushes to encourage the committee to move faster. But if after every revision we now have to consider the sum total of all the revisions before the next one can be released, the cycles will take longer and longer, and we'll never be able to go faster.

[FortranFan]

.. I think this would forever require Fortran to carry around the baggage of its past mistakes. One would not be able to make a new proposal without first considering all of the possible implications to all prior versions of the language. Of course it wouldn't be a good idea to have silent changes between consecutive versions, but to never be able to change the meaning of old code? ..

I agree with @everythingfunctional.

And I do NOT AT ALL think deletions are "silent changes".

And I do NOT think "One would not be able to make a new proposal without first considering all of the possible implications to all prior versions of the language" is a "good thing" at all.

Deleting "implicit typing as the default" and deleting "implied SAVE" in a future standard revision will in all likelihood be received far more positively than the 8 deletions already in the standard (c.f. Section B).

For example, a code such as

      I = 42
      END

can be allowed to be rejected by a future processor. By the way, every "legacy" code I have seen either already has "IMPLICIT NONE" (which was the most commonly used non-standard extension prior to Fortran 90) or "IMPLICIT INTEGER(I-N), XXX(A-H,O-Z)" (where XXX is REAL*N or DOUBLE PRECISION, etc.) and none of such code will be impacted by the deletion of "implicit typing as the default".

Similarly, a code such as

      INTEGER FUNCTION COUNTR()
      LOGICAL FIRST = .TRUE.
      IF (FIRST) THEN
          COUNTR = 1
          FIRST = .FALSE.
      ELSE
          COUNTR = COUNTR+ 1
      END IF
      END

can be allowed to be rejected by a future processor. But should the code have SAVE specification in some form (e.g., SAVE statement and/or LOGICAL, SAVE :: FIRST = .TRUE.), then deletion of "implied SAVE" will have no impact.

Moreover, if "implied SAVE" is deleted and processors support such a change by default, quite a few purse-string holders I know will only be happy and start to view Fortran a little more positively.

Note it's already the silent introduction of vulnerabilities in code such as via "implicit typing" and "implied SAVE" that bothers many a manager.

[FortranFan]

@certik wrote:

.. for example if an implicit save now becomes implicit init ..

@certik , please note what I've been suggesting is only for "implied SAVE" to be deleted, not that "implied SAVE" becomes "implicit init".

My own suggestion, as I've mentioned in other issue threads, is for no more "implicit" semantics.

• So if coders want "SAVE" behavior, it must be instructed explicitly. An example, logical, save :: first = .true

• And if coders want initialization, to instruct so explicitly - say if INIT keyword is introduced, then perhaps using integer, init :: x= 42

[certik]

@FortranFan regarding your last comment, yes, that is the minimal proposal that we seem to get an agreement in #40. I plan to write it up soon. (Yes, I do think we want more, but we do not have an agreement on that.)

@klausler yes I agree @everythingfunctional could have formulated it better also. Thank you for explaining it.

[gronki]

Sorry for being inactive in this board for a longer while.

Can I ask those who are familiar with arguments that are actually held by the standarization entity: what is actually the reason behind absolutely strict preservation of backward compatibility in some cases (such as: making implicit none as default) and less strict in other cases (some features have been deleted from the language). As far as I understand, 99% of the codes would not have issue with introducing one line of code that re-enables some obsolete features. If for some reason this is not possible, the remaining 1% can use compiler switches that compiler vendors will certainly provide. I do not understand how holding back the development of the language is in any way explained by few codes that could potentially require re-certification.

I feel the "backwards compatibility" argument is used very inconsistetnly and only where it is convenient and the supposed penalty for doing that is highly exaggerated. After all, it's not the language gets obsolete every 5 years: it is literally two or three features to be deleted that actually that recur in every discussion and that do hold back the language. And none of the proposals change silently the behavior of the language but they are better characterized by "hardening" or making code "strict".

I think there should be only one Fortran, the current one. It can still benefit from the power of legacy of F77 codebase, but I feel this argument is often exaggerated and overused to prevent good change from happening. I, personally, would be happy with "strict" or "hardened" or "explicit" or "modern" keyword as a middle ground that disables all terrible features without having to write 10 lines like "implicit this" and "explicit that" and that would also make backwards compatiblity a non-issue (if you use "strict", you keep code up to date cause it might become obsolete according to the the future revisions of the standard, if not, don't include it and you're good for the next 50 years).

[certik]

@gronki thank you for explaining your position. Your last comment is what I believe also that we should do. (I thought previously you were against doing what you just wrote.)

@sblionel you are the most prominent person on the Committee that is active here, what do you think? This is something I would like to discuss informally in person at our next meeting to see what others on the Committee think.

[sblionel]

@certik , I have already suggested to Dan Nagle that we spend a few minutes at the next meeting to discuss the general issue of backwards compatibility. I've written some on this topic already, but here are some more thoughts...

• Deleting features is worse than pointless, it is harmful. Compilers will not actually remove "deleted" features because too many of their users/customers will raise a stink if they suddenly have to rewrite code that has worked for years/decades. Or, worse, the users will just switch to another compiler that hasn't removed support. And by "remove" I include complaining about it by default and requiring some sort of build option to bring it back. From the standard's perspective, deleting features is harmful as it removes descriptions of how the deleted feature should work with other parts of the language.

• When people ask me what Fortran's strengths are, I always include its compatibility with a broad catalog of existing software, and that a (correct) program written in the 1960s probably compiles, builds and runs just fine in today's compilers. Yes, there are exceptions to this, but they generally relate to rarely used or inadequately specified features.

• Most of the discussions here of candidates for deletion are about fixed-form source, implicit typing and implicit SAVE. Fixed-form is already marked obsolescent, but it is still VERY widely used. Implicit typing is also very widely used in older codes, but the standard provides a simple way of removing it through IMPLICIT NONE, and compilers have options to default to that - I don't see the need to do more. Implicit SAVE is a much harder thing to remove, as it is a semantic behavior not a syntax, so a compiler could not detect whether the user intended SAVE semantics or not. I'd have no objections to adding SAVE to the F18 IMPLICIT NONE() list, requiring positive action on the part of the user. (Don't forget that DATA has implied SAVE since forever...)

I do not agree with those who argue that backwards compatibility prevents new features from being added. As I have already written, it can affect how we specify the new feature.

Last, I'm puzzled and disappointed at all the energy being devoted to this general topic, which I view as being a silly hill to die on. But I'm done here and will be interested in what J3 folk have to say about it next month.

[certik]

@sblionel thank you for the feedback, I really appreciate it. Let's discuss more at the meeting.

[FortranFan]

.. I do not understand how holding back the development of the language is in any way explained by few codes that could potentially require re-certification. ..

Can anyone please post here some basic information (name, domain, etc.) on FORTRAN codes making use of implicit typing that are in "production" use? Also, the ones which may have constraints such as software recertification?

[FortranFan]

As implied in my https://github.com/j3-fortran/fortran_proposals/issues/83#issuecomment-581449469, my impression remains the use of implied SAVE as deliberate intent that is part and parcel of code design is absent in codebases developed using facilities introduced with Fortran 90 and later standard revisions.

An improvement in Fortran which forces explicitness in terms of SAVE attribute (thus no implied SAVE) will be a tremendous blessing that helps many a codebase rather than prove detrimental.

[certik]

At the upcoming Committee meeting I would like us to

• Figure out what the Committee (as a whole) stance on this is
• Write it down
• Post it prominently in this repository, as guidelines how to improve the language (similar to the Python guidelines that @septcolor posted)

Then that would put the conclusion to this debate. But until we do that, we are not done here.

[FortranFan]

The change to NAMELIST in #67 is another situation (https://github.com/j3-fortran/fortran_proposals/issues/67#issuecomment-592231177) where backward compatibility is also of concern, "Changing the default behavior of namelist will change the behavior of existing programs. This may be done only for a very important reason, and a convenience issue, such as a default setting, likely does not rise to that level..

I do find the concern in this case rather odd because

1. the compiler behavior as per current standard makes it not particularly usable (a standard-conforming program can fail to input edit what it itself output!),

2. there are no identified "existing programs." that rely on current behavior, and

3. it's often alleged NAMELIST is used rarely.

So to do something here to improve the default behavior appears more beneficial overall (that may also make the practitioners employ the corrected NAMELIST facility more) than any cost due to a "breaking" change or by not doing anything.

[sblionel]

Backward compatibility was a concern on the NAMELIST change, sure, but more important was that the desired behavior could be easily obtained with already existing features, such as adding DELIM= on the OPEN, READ and/or WRITE. We’re generally disinclined to add “yet another way” to so something, and even less so to force a behavior that some might not want.

I’d also note that list-directed I/O is a place where you probably would not want this, and a blanket ignoring DELIM-‘NONE’ or changing the default does not add value. Restricting the change to NAMELIST adds needless complexity.

[marshallward]

I have modified #67 to make it clear that current list-directed output should not be affected.

And objection to greater complexity does not feel like a valid argument for me. It's a complex situation caused by the existing rules (i.e. namelist output formatted according to list-directed output rules) and is producing incompatible output. Why not introduce the necessary level of complexity which resolves the problem? (And given that GFortran is already doing the sustainable thing, I doubt it ought to be considered a complex rule.)

And I'm only raising this because I have supported and still support models which use namelists which get passed through workflow managers of greater complexity as times goes on. These problems with string formatting happen too often and take too much time to debug. And telling users to add a DELIM does not inspire faith in the language.

I apologize if this is getting off track from the larger conversation of retaining backwards compatibility. And I also fully understand that this isn't a serious problem for most Fortran users, which is already a very rarefied group. But I don't see the point in retaining backwards compatibility to something which is broken.