Add deallocate/reallocate option to ALLOCATE

[rweed]

This idea was originally proposed a few months back on C.L.F. b someone else so I'm echoing it here

Add an optional deallocate/reallocate logical argument to ALLOCATE to tell it to check allocation status of any variable in its allocate list and deallocate it prior to allocating to a new size if it is already allocated.

Example

Instead of having to code

If (ALLOCATED(A)) DEALLOCATE(A)
ALLOCATE(A(N))

do

ALLOCATE(A(N), REALLOCATE=.TRUE.) or
ALLOCATE(A(N), DEALLOCATE=.TRUE.) ! either syntax works for me

Basically you are telling the compiler to check allocation status and instead of issueing an error (absent the status variable), do the deallocation for me and then reallocate.

This can save several lines of code if you have a lot of dynamic arrays that you need to periodically resize

[certik]

@rweed actually this would be very useful. I often have code like this to run some convergence study:

do i = 1, max_iter
    n = n * 2
    allocate(A(n), B(n), C(n), ...)
    ....
    deallocate(A, B, C)
end do

So it would get reduced to just this:

do i = 1, max_iter
    n = n * 2
    allocate(A(n), B(n), C(n), ..., reallocate=.true.)
    ....
end do

That way one does not need to repeat 10 arrays in the deallocate statement and remember to deallocate when I add another array.

[FortranFan]

@certik wrote:

@rweed actually this would be very useful. ..

Here's a recent thread at comp.lang.fortran forum on this, perhaps the same as what @rweed mentioned.

I wrote in that thread, "what interested users can do is to make a case for enhancements such as this in the standard and put a together a proposal paper for submission with one or more contacts listed at the WG5 Fortran website. GitHub is a good platform for users to group together and collaborate to capture their needs, collect use cases, and summarize what is of interest for an enhancement or addition to the language. The standards committee can best work on the response: either No, or if at all yes, as to how and when!"

Mega Kudos to @certik and @zjibben for making GitHub happen!

Now, if only WG5 Fortran can follow "common sense" which will be to not proceed with a "frozen" work-list with J3 on Fortran 202X revision! Rather they can follow a somewhat open approach which allows work to proceed on many good ideas based of course on some objective, initial screening. Then, in this day and age of modern collaborative platforms such as GitHub and amazing multitasking abilities of interested and multi-talented folks, considerable progress can occur online in parallel and near-ready features for official standard publication can be developed. so much so that committee can increasingly be in a critical review mode, to cross-check and resend for correction or refine work, thereby saving themselves so much time. What is needed mostly are some guidelines or criteria - clearer the better - on what to do or not do in terms of additions/changes to the Fortran standard.

Delegate to develop faster is what the committee can best do for Fortran.

Many, many ideas like the one with ALLOCATE statement in this thread can then be absorbed into the next revision.

It is then too bad something like this will have to wait for Fortran 202Y.

[rweed]

I would like to add that modifications like this fit my criterion for things that the committee should give priority to above adding new capabilities that will take much longer to develop and implement. Namely,

1. Its a (on the surface) straightforward and simple extension to an existing cabability. I doubt if implementation will require more than a few lines of code

2. Its something that most users will probabaly use immediately (or at least when it becomes available in their compiler of choice). While many of the new proposed features are interesting and I'll probably find a use for them some time in the future, very few of them are things I would use right away. There are still some proposed features (and things in the current standard) that I'll probably never use and appear to me to have been (or are) the pet project of one of the committee members that addresses a narrow focused need in their own work or their organization.

Therefore (and this this touches on issue #36) I would like to see the committee priortize their work along these lines.

1. Simple and quick to implement and most members agree would be adopted and used by the user community immediatly
2. Improvements and extensions that will take much longer to implement but address a clear need or deficiency in the langauge but still might not be immediatly adopted by the user community
3. Things that address only an application specific area and would not be widely used

I would move as suggested to a 3 year development cycle with the first 1.5 years addressing an agreed upon number of priority 1 items. This could be released as an interim standard (a TS or TR) some time between year 1 and 2 and allow the developers to implement them prior to the release of the full standard. Concurrently, Priority 2 items can be developed over the full 3 year cycle. Priority 3 items could be pushed into a five year cycle

I strongly agree with @FortranFan that the current development process is too inflexible and doesn't allow for items that have an obviously short development and implementation cycle to be added in a specified window after the initial feature set for each standard revision is agreed upon

[certik]

@FortranFan, @rweed thanks for the feedback. I think we are all in full agreement how this should work. I just posted in a similar spirit at https://groups.google.com/d/msg/comp.lang.fortran/dFenjU25o9k/TaLSwNS3DQAJ.

Now, in order to move forward from here, can you please both help me in the issue #26 to formalize what you just wrote above? We need two documents:

• a document that will summarize how we want to work in this repository and that proposal does not require any changes how the committee itself works. Well, except one change: the committee must give feedback to any solid proposal submitted to it at any meeting.

• a formal proposal to the committee how the committee itself should work and why. That will require changes to the committee. As such, the committee might say no, and explain why. And we will work as community to address such objections.

It's important however to have this written up in documents, and truly think all the arguments out (let's collaborate on that), so that when committee members read it, they can say: "These are really good points, why don't we try that?". Such a document also gives me and many others on the committee something to bring up and collect feedback on. (As opposed to just a GitHub issue.)

---

If you are for it, why don't you just post a draft of such documents into #26 as comments, and then we'll create a PR and create an actual document, once we can agree on the wording.

[jacobwilliams]

Why not just make this the default behavior of allocate? Is there ever a situation where you want the current behavior (crashing if it is allocated?) I would say no.

[certik]

Is there ever a situation where you want the current behavior (crashing if it is allocated?)

I think I want this behavior while developing, to catch double allocation bugs. I think the user should specifically say when reallocation is wanted, otherwise it should give an error.