09-218
To: J3
From: Malcolm Cohen
Subject: About the feature request in 09-207
Date: 2009 April 30
References: 09-207


1. Introduction
---------------

Paper 09-207 makes a feature request for auto-reallocating assignment.
This paper makes some observations about that feature request.


2. The feature request and discussion
-------------------------------------

Consider
  REAL,ALLOCATABLE :: x(:)
  ...
  x = 3  ! Any scalar expression, "3" Without Loss Of Generality

The current draft and F2003 corrigendum 3 (interp F03/0093) both require
that at the point of the broadcast assignment, X shall be currently
allocated.  The rationale being that if X is not allocated, one does not
know what array shape to broadcast the scalar to.

Paper 09-207 says
  "Presumably, if the ranks differ, the processor is expected to produce a
   runtime error message and stop the program."

Of course the processor is permitted to do anything it pleases.  In fact,
the obvious thing to do once one knows that auto-reallocation is not on the
table is not to emit the auto-reallocation instructions.  Given the usual
implementation techniques, doing a straight copy into an unallocated
allocatable will be trapped by the hardware ("Segmentation fault") which
indeed would terminate the program with an error message.

Paper 09-207 goes on to claim
  "It would be easier on processors if..."

I dispute this in the strongest possible terms.
There is NOTHING that can be easier than the freedom to do as one pleases.
That the hardware automatically detects the error for free in most cases
is mere icing on the easiness cake.

Paper 09-207 then proposes that
  "if <expr> is scalar and variable is an unallocated allocatable array,
   variable is allocated with all upper and lower bounds equal to 1"
(and that the restriction is removed).

It might be argued that this new feature would be more convenient for some
users, but that is not what the paper says.


3. Disbenefits of the feature
-----------------------------

Obviously the feature imposes a small additional implementation burden on
the implementor.

It is also obvious that even if not used, it imposes a small additional
performance cost on the user, when the processor cannot work out at compile
time whether an allocatable array is allocated.

I would further say that:
 (1) the behaviour of broadcast is very different from that of creating a
     new array object with a single element,
 (2) it is very easy for the user to specify that one wants a new object
     with a single element (in the example above, "x = [3]"), and
 (3) it is very easy for the user to manually detect the error of assigning
     a scalar to an unallocated allocatable ("If (.Not.Allocated(x))").

I further contend that this feature would not noticeably enhance the
reliability of Fortran programs because:
 (i) if the user wants this behaviour, he can very easily write it himself;
 (ii) if the user does not want this behaviour and programs defensively,
      he can detect the fault easily and take appropriate action;
 (iii) if the user does not want this behaviour and programs carelessly,
       this feature would mean that he would likely get silently wrong
       results instead of a program crash.


4. Summary
----------

The feature described in paper 09-207 does not appear to have such great
benefits as to significantly outweigh the obvious disbenefits.

===END===