Optional conditional reallocation in allocate (`reallocatable` attribute)

[certik]

First requested at https://fortran-lang.discourse.group/t/is-allocate-a-function-or-subroutine/2771/6. See also https://fortran-lang.discourse.group/t/reallocatable-attribute/5914 for a more general approach.

It would simplify a lot of my code if allocate() had an optional argument to trigger conditional reallocation of an existing array. Say something like

allocate( a(lb:ub), conditional_reallocation=.true. )

If a(:) is already allocated with lower bound lb and upper bound ub, then nothing happens, the array is unchanged. If a(:) is already allocated with the correct size but with different bounds, then the bounds are changed but the contents of the array would remain unchanged. If a(:) is already allocated but with a different size, then it is deallocated and reallocated with the new size and bounds. All of this can be done now with some trickery, but these common operations should be a standard part of the language.

[shahmoradi]

Even better, in my opinion, would be a new statement resize() without further complicating the existing allocate() interface, which would also avoid the need for the lengthy optional argument conditional_reallocation. This facility was so crucial and helpful that it justified the excruciating effort of writing 20,000 extra lines of code in our library to allow generic resizing of intrinsic type objects and custom containers.

[jalvesz]

I'll bring here some of the comments made on the forum.

• Yes, native support for reallocation in the language is a must. We also went to great lengths to create a "generic" function interface to manage that for several permutations of intrinsic types and dimensions. No surprise, we named it "reallocate", it internally uses allocate + call move_alloc to manage dynamic reallocation.
• Given a hypothetical situation in which allocate statement can do reallocation, I see no practical need for such a lengthy extra argument. One can already know if the entity has been allocated with "allocated(myarray)". So, if one doesn't want to reallocate, then doing "if(.not.allocated(myarray)) allocate( myarray( ... ), ... )" would suffice. Unwanted dynamic reallocation of small temporal working arrays can be catched with tools such as VTune and others. In that case, small arrays might better be moved to the stack rather than being "allocated".

So, my 2 cents here are: better to integrate reallocation within the already existing allocate. Does an extra argument is required? I think not but would honestly want to see a practical reason for which it would be really needed.

[PierUgit]

Here is a proposal, with a demonstration code: https://github.com/PierUgit/enhanced-allocatables

I have defined a resize routine that would be a new statement if integrated in the language, but it could be as well an extension of the current allocate (with some drawbacks in my opinion)