(j3.2006) Is 7.2.1.2p1(1) necessary?

Van Snyder Van.Snyder
Fri Mar 13 17:59:25 EDT 2015


On Fri, 2015-03-13 at 12:01 +0900, Malcolm Cohen wrote:
> Alternative means of doing "safe polymorphic assignment" could exist
> if we 
> wanted them to, e.g.
>    WHEN SAME TYPE ASSIGN(x = y)
>   OTHERWISE ERROR STOP
> or even
>    WHEN SAME OR EXTENDED TYPE ASSIGN (x = SAME TYPE PART OF y)
>   OTHERWISE CONTINUE

We already have

  if ( .not. SAME_TYPE_AS ( x, y ) ) &
    & error stop 'Dynamic types of X and Y differ'
  x = y ! NOT ALLOWED IF X IS POLYMORPHIC, even though
        ! the types are clearly identical!

We also have

  allocate ( x(2*size(y)), MOLD=y )
  x(1:size(y)) = y ! NOT ALLOWED IF X IS POLYMORPHIC, even though
                   ! the types (and type parameters) are clearly
                   ! identical!

Sometimes you DO NOT WANT identical types.  If X and Y are both
unlimited polymorphic, and both of numeric type, you MIGHT WANT to allow
the same conversion as would be allowed by Table 7.8.  We don't have an
easy way to do this.  One would need nested SELECT TYPE constructs with
a total of 25 branches, assuming one only wants to handle one kind of
integer and two kinds of real and complex.

We also have

  type :: T ( L )
    integer, len :: L
    integer :: C ( L )
  end type T
  ...
  subroutine S ( X, Y )
    type(t(*)) :: X
    type(t(*)) :: Y
    x = y ! This is just as dangerous as assignment to a non-
          ! allocatable polymorphic variable, but X is NOT
          ! required to be allocatable!

I don't see how the "safety" gained by requiring a polymorphic variable
to be allocatable is sufficiently more valuable than the safety NOT
gained by NOT requiring a variable with length parameters to be
allocatable and to have all parameters deferred.

Not being able to assign to a polymorphic variable that is not
allocatable, which especially importantly and frustratingly includes the
case of an array element, makes it impossible to write container classes
without strenuously gymnastic kludges.  Or maybe I'm just too dense to
see how to do it, at least without resort to a preprocessor.

It is astonishing that the committee is obsessed with this tiny fillip
of type safety, but repeatedly rejects support to check and convert
units of measurement, failure to address which can (and has) caused very
expensive problems.





More information about the J3 mailing list