Will FORALL be deleted?

FORALL is obsolescent in Fortran 2018. I believe that is because the initial aim of helping compilers parallelize code has not been realized and because DO CONCURRENT is now available.

I still like FORALL and hope it will be retained, because it is concise and indicates that the operations within can be done in any order. I see that a GSOC student has implemented it in LFortran.

How likely is it that FORALL will be deleted in future standards? The F2018 interpretation says “A future revision of this document might delete an obsolescent feature if its use has become insignificant.”


Even if the standard deletes forall, I doubt if compilers will ever do so.

1 Like

Certainly, FORALL is eligible for deletion, but I doubt it will happen. I know that several on the committee agree with me that deleting features from the language is counter-productive. As @shahmoradi notes, compilers won’t drop support and deletion removes any text that explains how the deleted feature works with other parts of the standard.


Indeed, as others said, compilers most likely won’t remove the support for it, and even new compilers being developed (such as LFortran that you mentioned) have to implement it, because existing codes use it.

Once a feature is standardized and some codes start to use it, it has to be supported pretty much forever in practice by compilers. It is for this reason that I encourage the Standards Committee (myself included) to be extra “conservative” when adding any new feature into the language, because it is “forever”, and so it should be “worth it”.

Indeed, the standard specifies that the iterations can be executed in any order, but not necessarily always in parallel (i.e., intermingled). See this answer by Robert Corbett in the J3 mailinglist for more details:

[J3] Questions about DO CONCURRENT and locality

1 Like

In fact there is a strong argument to be made to undo the obsolescence of FORALL, it is effectively just a label in the standard, and it can just as readily be removed as applied. For all the compilers worth their salt are going to support it any way!

The point in the standard about it being redundant with DO CONCURRENT is not quite accurate. FORALL is both a statement and a construct; the former is handy.

In this thread, I was quite tempted to suggest FORALL but I didn’t only on account of its label in the standard:

forall (integer :: i=1:size(a)) a(i) = xx ! where xx is a valid const-expr 
1 Like

a(:) = xx is not all better in our experience where
a) the array section notation (:) has been found to be confusing and practitioners misunderstand and/or misuse it;
b) depending on the expression(s) presented with xx, the array assignment can involve array constructor or ac-implied-do on the RHS that both compilers and coders haven’t always handled well, and
c) there are situations with certain loop-based assignments involving expressions, especially in certain environments with mixed-language applications, where code reads better left-to-right and the FORALL statement serves the needs well.

In that other thread and here, my responses have qualified the RHS for the broader scenarios of fairly common interest to practitioners.

In recent years there has been a high bar for actually deleting features. Particularly if compilers still support the feature because old codes use it. The point of obsolescent is to discourage new use of the feature. An example of a deleted feature that comes to mind was the arithmetic IF statement, since its semantics depend on > and < tests that became problematic when the concepts of IEEE arithmetic (with NaN) were introduced into the standard. Similarly, the PAUSE statement was deleted because its purpose had an implicit assumption that the person running the program was sitting at the computer’s console. Not the case anymore, in actual practice.