(j3.2006) Requiring identity of polymorphic arguments' declared types is too strong

[Van Snyder]

The requirement that allocatable or polymorphic dummy and actual
arguments have the same declared type is too strong.

If they're not pointers or allocatable, the dummy argument only has to
be type compatible with the actual argument.  This guarantees that at
least all of the dummy argument is associated with something.

We imposed the requirement that the actual argument is also type
compatible with the dummy argument if its a pointer or allocatable (and
therefore the declared types are identical) so that if the dummy
argument is allocated at least all of the actual argument exists.

This could be imposed during allocation, allowing the weaker requirement
that the dummy argument is type compatible with the actual argument
instead of the stronger identical declared-type requirement:  If the
allocate-object is a polymorphic dummy argument and a type-spec doesn't
appear, it is allocated with the declared type of the actual argument,
not the declared type of the dummy argument.  If there is a type-spec or
source-expr, and it's not type compatible with the actual argument's
declared type, a run-time error occurs (instead of a compile-time
error).

This would work even if we allowed the actual argument to be monomorphic
and a pointer or allocatable even if the dummy argument is polymorphic.
A type-spec or source-expr in an allocate statement would then have to
be the same type as the type of the actual argument.

Processors could issue a warning (or a "questionable" message) instead
of an error if the actual and dummy arguments are pointers or
allocatable, and their declared types aren't the same, or the actual
argument is monomorphic and the dummy argument is polymorphic.

I was obstructed by this while trying to create a list of polymorphic
objects.  I want to allocate a new object, put some basic stuff into it,
and link it into the list.  Then, after returning, add stuff to the
extension part of the object that depends on what the object actually
is.  I think the problem would appear for any polymorphic container, not
just a single-linked list.

I developed three kludges to work around it.  One was to allocate the
object first and then pass it to a nonpointer nonallocatable polymorphic
dummy argument to be filled and linked.  This was more of a kludge than
the other solutions because the type had a length parameter that
depended upon the basic stuff to be filled.  One was to write routines
with different characteristics, and use an INCLUDE statement to fill
their identical bodies.  Another was to pass in an optional "mold"
argument to allocate objects of types that are extensions of the dummy
argument's declared type; this also needed to calculate the length
parameter in advance.  Instead, I moved the length parameter from the
type to some components and allocated them.  Fortunately, the MOLD in an
ALLOCATE statement can be an undefined or disassociated pointer (if it's
a scalar with no deferred length parameters), so I didn't need to have
an entire object for each type.  A fourth kludge that I rejected was a
SELECT TYPE construct inside the otherwise-simple routine.  It could
have been simpler, and I wouldn't have spent all day developing three
kludges and agonizing about which was the least worst (and writing this
message), but for our "identity" restriction.

Is there a technical reason not to change this in the next revision?