(j3.2006) question about generic resolution

[Van Snyder]

On Tue, 2010-03-23 at 19:02 -0700, Malcolm Cohen wrote:
> >> The "POINTER vs ALLOCATABLE" generic feature is fundamentally
> >> misguided.
> > I do not agree with this statement---this feature does have uses, and
> > this has been debated in WG5, which voted to put it on the list.
> 
> Well, we voted to put it on the "Allowed" (not "Required") list.

I'm the one who wanted this feature.

I want to be able to write a single generic to allocate both pointers
and allocatables, and a single generic to deallocate them.  I can think
of a few other less important but still good reasons to want to glue
them together, such as changing the sizes of databases, which has to be
done differently for pointers and allocatables (pointer assignment vs.
move_alloc).

Our Allocate_Test routines started out just doing three things: Allocate
a pointer, test the allocation status, print an error message and stop
if nonzero.  We've added a bunch of performance monitoring and
statistics gathering stuff.  Similarly for the deallocate_test routines.
We're happy that we wrote them, instead of trying to enforce a
programming style that requires all that stuff.  We would never have
retrofitted the performance and statistics stuff onto inline code for
just the first three jobs.

Given our staffing level, we're stuck with pointers for many of our
structures for which allocatables would be more attractive now that we
have 15581 in essentially every f95 compiler and integrated into f2003,
unless we want to track down and change every call to allocate_test and
deallocate_test for a pointer that we want to change to allocatable.

If there were a way to allow either a pointer or allocatable actual to
correspond to an allocatable dummy, or perhaps to a pointer dummy
instead, or to allow all four combinations, the pointer vs. allocatable
generic resolution wouldn't be necessary.  I suspect this isn't
workable.

For me, it would be undesirable but not a disaster to see the
allocatable vs. pointer resolution feature go.

If I ever get the time (or an assistant) I can work around the problem
by replacing calls to allocate_test with an allocate statement followed
by a call to test_allocate, which does everything allocate_test does
except the allocation.  This is more feasibly useful now that we have
storage_size.

This is less attractive than having allocate_test for both allocatable
and pointer, but more attractive than having a differently-named generic
of the same functionality as allocate_test but for allocatables, because
I know that once I make the change I won't have to change it back if
ever I discover a reason a pointer I changed to an allocatable has to be
changed back to a pointer.