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

[Van Snyder]

On Fri, 2015-03-13 at 09:20 +0900, Malcolm Cohen wrote:
> >> >Would it be enough
> >> >to require that if it is not allocatable, variable and expr shall have
> >> >the same dynamic type?
> >>
> >> Not compile-time checkable.
> >
> >If we made everything compile-time checkable, nobody would use Fortran.
> 
> Since we did make the object-oriented stuff type-safe, i.e. compile-time 
> checkable, then it seems that nobody is using Fortran.

The object-oriented stuff is not "everything."

> >This is yet another of the unhelpful "helpful" restrictions about which
> >I wrote yesterday.
> 
> It's not a programming style restriction any more than a seat belt is a fashion 
> accessory for car users.
> 
> >  It's purported benefit can be gotten easily --
> 
> Contrariwise.  Programs in other languages written with non-type-safe 
> polymorphism are typically littered with type errors, and these are really hard 
> to track down.  It would be a disbenefit to our users to provide such an 
> error-prone feature, as it would significantly increase the cost of using 
> polymorphism safely.

I don't know other languages with polymorphism well.  I suspect they
don't expect the runtime to check the dynamic types during assignment.

Type safety isn't compromised by what I propose.  It just means that you
must either
  (1) prove a theorem that the dynamic types are the same,
  (2) check the types yourself using SAME_TYPE_AS,
  (3) make the variable allocatable, or
  (4) expect a runtime error (not silent corruption), perhaps long after
      you deploy the code.

7.2.1.2p1(8) requires corresponding nondeferred length type parameters
to have the same values, but this is not compile-time checkable.  Does
this significantly increase the cost of using PDTs safely?  Should we
have perhaps required the variable to be allocatable and to have only
deferred length parameters?  That would make the assignment
length-type-parameter safe.

> >Its harm is greater than its
> >benefit:  Assignment to elements of polymorphic arrays is messy.
> 
> Direct assignment to an element of an array whose type is 
> unknown-at-compile-time is inherently messy.

What if I can prove a theorem about my program that the dynamic types
are equal?  What if I've inserted a SAME_TYPE_AS test and responded to
the possibility of different dynamic types using a mechanism of my own
choosing, i.e., something other than reallocating the variable or
crashing with an inscrutable message?  Should I still be required to
make the variable allocatable?  What if I've inserted an ASSERTION that
the dynamic types are the same ... oh, wait, we decided not to provide
that.

> Could we design a type-safe assignment for this case?  Yes we could.  Some new 
> syntax would be needed, but it's certainly not impossible to do.

We already have a type-safe assignment for this case.  It's SELECT TYPE.
To assign polymorphic objects for which a theorem proves that their
dynamic types are necessary the same, one nonetheless needs a nest of
two SELECT TYPE constructs.  If you don't include any CLASS DEFAULT
branches (and why would you, if you know the dynamic types are
correct?), that's "only" seven lines of code to do what one line ought
to do.

> Is it worth it?  That is a difficult question.  Obviously it's too late for 
> F2015 anyway, but even for the next revision there are umpteen features 
> competing for both committee and compiler vendor resources, and although this in 
> itself is perhaps not terribly big, it does not look terribly high priority to 
> me.  But that is a discussion for another day.
> 
> As Tom Clune remarked, oftimes a method (type-bound procedure) provides the best 
> solution for times like this.  I agree with his comments.

Color me dense, but I haven't figured out how to do it without SELECT
TYPE, at least in the case of assigning a (polymorphic) value to a
component of a polymorphic array component.

> Cheers,