(j3.2006) (SC22WG5.4645) Vote on N1904

[N.M. Maclaren]

Please answer the following question "Is N1904 ready for forwarding to SC22
as the DTS?" in one of these ways.

3) No, for the following reasons:

    (A) Page 9, C407a and page 13 6.3 paragraph 3.  Email discussions
arising from Tobias Burnus's attempt at implementation indicate that
there are still significant problems with this and actual arguments that
have ALLOCATABLE or POINTER components, default-initialized components,
final subroutines, and perhaps more.  Components with polymorphic types
may also be a problem, but I do not completely understand the existing
constraints on those.

These were considered during its design, but seem to have been
underestimated.  With hindsight, I feel that the specification of
TYPE(*) is far too liberal.

Note that the proposals to simply forbid INTENT(OUT) together with
assumed-type exclude reasonable uses of INTENT(OUT) (e.g. for MPI
receive buffers), but some constraint along those lines seems the best
solution.  The following is badly worded and may not be enough, but is
put forward as a possibility:

"If the actual argument corresponding to an assumed-type dummy argument
is of a type with default-initialized components, or of a type that has
has components that have the ALLOCATABLE or POINTER attributes, or are
of types with default-initialized components, the assumed-type entity
shall not have the INTENT(OUT) attribute."

I also feel that the lack of any such restrictions on INTENT(INOUT) or
no INTENT is very confusing, and will be misunderstood by some readers
who were not involved in the discussions; the following is a draft of a
note that might clarify the intent.

"NOTE 5.3 The purpose of assumed-type is to allow companion processors
to handle Fortran variables with arbitrary, but simple, types as raw
data or raw storage.  All uses of it will be processor dependent, and
uses incompatible with Fortran syntax or semantics will be undefined."


    (B) Page 10, C1255 and C516.  Reinhold Bader's point (H) explains
that this has similar, though probably simpler, forms of the same
problem, and I remain concerned about polymorphic types.  I believe that
the restriction should be that all non-assumed-type dummy arguments to
BIND(C) procedures should be of interoperable type, and interoperable
except that they are allowed the ALLOCATABLE or POINTER attributes,or
are of assumed shape, type or character length.

No wording is provided, though John Reid has posted a possibility on
the WG5 reflector.


    (C) Page 20, 8.3.4 paragraph 8 and page 31, 8.7 paragraph 5.  This
should also exclude components with type parameters, type-bound
procedures, final subroutines and possibly default-initialized
components and polymorphic types.


    (D) Page 14 6.4.3.  This does not describe the case of no DIM
argument for UBOUND.  Better wording would be:

The description of the intrinsic function UBOUND in ISO/IEC 1539-1:2010
is changed for an assumed-rank object that is associated with an
assumed-size array; if DIM is present and equal to the rank of ARRAY,
the result of UBOUND(ARRAY,DIM,KIND) has a value equal to
LBOUND(ARRAY,DIM,KIND)-2 with KIND omitted from LBOUND if it was omitted
from UBOUND; if DIM is not present, the element RANK(ARRAY) of the
result vector has a value equal to LBOUND(ARRAY,DIM,KIND)-2.


    (E) Passim.  The term used in the standard is "final subroutine",
not "final procedure".  This should be changed.


    (F) 8.3.3 elem_len.  Kind is not a C concept.  "and kind" should
be removed.


Regards,
Nick Maclaren.