Disallow use of new features when an obsolescent/deleted feature is used

[sblionel]

There have been proposals to delete certain features without making them obsolescent first. Others have suggested that certain obsolescent features, namely fixed-form-source, make it hard to add certain new features. There is also the ongoing concern that users are still being taught obsolescent features and keeping them in programs as they are maintained.

Given that compilers will be required, by their users, to continue supporting deleted features, I am not in favor of deleting more features. Deletion also removes words from the standard explaining how such features work with the current standard, creating problems for users and implementors alike.

I propose that the standard disallow use of new features (the standard would provide a list) in any program unit where an obsolescent or deleted feature was also used. This would allow continued use of old sources while encouraging programmers to switch to modern features if they wanted to use newly added ones. In particular, fixed-form source would have to be converted to free-form. Instructional material would tend to not teach the obsolee/deleted features - the descriptions of these could be moved to a separate clause (not an intrinsic part of this suggestion.)

[klausler]

I can imagine having to explain to a paying customer that they can't use some shiny new feature in one part of a program unit because it contains an assigned FORMAT in another unrelated part, and that the compiler actually went out of its way to needlessly disable the shiny new feature. And then trying to explain why this is somehow in their best interest, even though there's no technical reason why the shiny new feature had to be disabled.

I think I'll opt out of this one, thanks.

[sblionel]

So a lot of people here are suggesting flat out deleting certain features. Fixed-form source is often called out as preventing certain new features from being added (not that I agree with this.) If features were deleted, the paying customers would be even more upset that their programs either wouldn't compile at all or would get diagnostic messages. It would also mean no documentation on what those features do.

Many have also expressed a desire to nudge users harder into refactoring code to use more modern features. There have also been suggestions for some sort of syntax to say "Hey, new features here!"

My proposal doesn't affect existing code, and gives more freedom to new feature design.

[waynelapierre]

This is a great idea and seems like the one way to move forward.

[FortranFan]

@sblionel , I like your proposal and generally understand and agree with the points you have made here and elsewhere about backwards compatibility and the burden on the practitioners with the continued use and maintenance of existing code bases and the demand on implementors on continued support of earlier features.

However my concern remains with a position that can come about where nothing can ever be deleted from the standard. A progressive, evolving language means to me that at crucial junctures certain prior aspects that have outlived their utility need to be removed.

As you may recall, I believe there are a few overarching semantics in the standard as opposed to "features" per se - "implicit mapping" and implied SAVE to be specific - that have long proved and continue to prove to be far more costly than yield any benefits in the domains of my experience and representation. Our need is arriving at a state soon with Fortran with the following:

1. implicit mapping is removed from the standard and thus implicit none is the default in every program unit and interface body but which legacy codes can override, if they so choose, with their own IMPLICIT statements but that a standard-conforming code is not required to insert implicit none to achieve explicit typing, that the standard explicitly calls for a conforming processor to detect and report a missing declaration when a relevant IMPLICT statement is absent and thus new codebases striving to conform to the standard can start to contemplate proceeding without the need to place implicit none everywhere. This is extremely important to us.
2. Similarly with implied SAVE, we would like to be in a situation where we would very much want the standard itself to require a conforming processor to detect and report a missing SAVE with the assignment-based initialization on a type declaration.

With the above two aspects, the implied route of your proposal with the standard->obsolescent->disallow only with new features but never delete is of little to no help.

So can "implicit mapping" and implied SAVE be treated outside the scope of your proposal and get those semantics get evaluated separately for removal?

[johnwcowan]

I think that this is too blanket. If you want to disallow old feature A and new feature B to coexist because it causes problem AB, then put all such (A, B, AB) instances into the standard. This will take some thought and careful work, but that's the price of backward compatibility.

[PierUgit]

@johnwcowan The problem is that as the language evolves with more and more features, the number of possible interactions between the features somehow exponentially grows, and at some point the standard will be much too complex. So we are left with two strategies: 1) deleting some old features, or 2) limiting one way or another the possible interactions.

I fully agree with @sblionel that old features should not be deleted from the standard, as long as compiler writers do want/need to include them, because they need to know precisely how these features have to behave. So IMO we have to find a solution to limit the possible interactions. My personal preference is towards #83 , but there are other possible ways.