(j3.2006) (SC22WG5.5804) [ukfortran] Straw ballot on four small technical changes

[Cohen Malcolm]

>I shall be very happy to change my NO votes if someone points out
>that I have made mistakes.

The primary mistake is thinking that we are voting on the edits to the 
draft.  We are not.

We are voting on the technical changes, at the feature level.  I'm sure the 
technical nitpicks are welcome input for further improvements, but they are 
not what we are voting on now.

>06-280r2
>
>Point 1:
>I had to read this several times to be quite sure of what it was saying.
>I suggest adding an extra question and answer:

Lacking a working time machine, it is not possible to add anything to the 
papers that will be passed by J3 meeting 211 which finished several weeks 
ago.  Since this would have no effect on the standard...

>06-285r2
>
>I think that we have two meanings of deallocate in the standard.

That would be mistaken.

>  But,
>whether we do or not, the last sentence of [84:32 7.5.6.3p2] is
>baffling

And what is more baffling is that this sentence which is not part of the 
feature being described in the paper, and does not affect in any way that 
feature, is being given as a reason not to have the feature.

The sentence that is allegedly baffling appears only in the paper because an 
earlier sentence in the paragraph has a minor editorial change, so we give 
the "making the whole paragraph read" result.  It literally has no effect on 
the feature being added (clarification of ordering when intrinsic assignment 
affects an allocatable finalizable subobject) because that case is excluded 
from consideration by the preceding sentence "... except ...".

The paper perhaps should have included an example, but one can just go back 
to F08/0013 (Corrigendum 1, see N1907 for the interp) and imagine that 
instead of the whole variable being allocatable, it is an allocatable 
component.  That's it.  I.e. where the interp has
      Type(t1),Allocatable :: x(:)
      x = ap1 ! (*1)
imagine it has
      Type wrapper
        Type(t1),Allocatable :: x(:)
      End Type
      Type(wrapper) w
      w = wrapper(ap1) ! (*1)
etc.

Armed with this understanding, one should be able to decide whether we ought 
to clarify that the effects on the hypothetical W%X are the same as the 
effects on the hypothetical X, by voting YES.  Or by voting NO, that we 
should keep programs that have such assignments non-conforming.

(BTW the sentence being suggested for deletion, which has nothing to do with 
this feature, is important so is not going to be deleted any time soon.  I 
decline to debate that sentence at this time however, as that would turn a 
red herring into a red halibut.)

>06-277r1
>
>C_SIZEOF is not permitted for an assumed-size array [486:24 18.2.3.7p3],
>but we permit assumed-size arrays to be actual arguments corresponding
>to assumed-rank dummies.  This inconsistency needs resolving.

That is a very fair comment for further improvements, but the question on 
the table is whether we should do the feature, not whether we should get the 
wording right (the answer to the latter being "yes of course!").

>  One change would be:
>
>    [486:24] 18.2.3.7p3 delete "that is not an assumed-size array".

This is not addressing any inconsistency; we decided (a long time ago) that 
it was perfectly fine to continue to prohibit assumed-size arrays from 
appearing in contexts which required their shape, while allowing 
assumed-rank arrays to appear n such contexts, and with well-defined 
semantics if associated with an assumed-size array.

See for example the LBOUND, UBOUND, SHAPE and SIZE intrinsics.

>    [486:31] 18.2.3.7p6 append "if the argument is an assumed-size
>    array or is an assumed-rank object that corresponds to an
>    assumed-size actual argument, the value returned is -1."

However this suggestion would break the identity
  C_SIZEOF(X) = SIZE(X)*STORAGE_SIZE(X)/STORAGE_SIZE(C_CHAR_'X')

We went to the trouble to specify SIZE and SHAPE that are consistent for 
this case, IMO it is better maintain that consistency in this case... (or 
just prohibit C_SIZEOF when assumed-rank X is associated with an 
assumed-size array)...

...***IF*** we do the feature.  You need to vote YES or NO regardless of how 
the technical nits are picked here.

Cheers,
-- 
........................Malcolm Cohen, Nihon NAG, Tokyo.