Re: Derived types and allocatable

Jan Vorbrüggen wrote:
>> I too wish they had given the same meaning to all four variants.
>
> I don't think that can be done. On the LHS, A(:) is a slice, and
> therefore must be allocated and defineable for the assignment to have
> a meaning at all. Think about it - what if I wrote:
>
> A(::2) = B
>
> What semantics would you ascribe to this assignment in case A is not
> allocated in a conformable way?

Actaully A(:) is easily recognizable as a slice that corresponds
to the whole array.  A(::2) is easily recognizable as a slice
that does *not* mean the whole array.  What I wanted was that
if the left-hand side is not subscripted (the whole array) or is
subscripted with only colon (:) in each subscript position,
the meaning should be the same.  It's an easily recognizable
syntactic form.  If the subscripts in each dimension *aren't*
merely colon (:), then the thing should follow the existing
rule for slices (even if the bounds expressions on the
subscript triplets turn out to refer to the whole aray).

Hence:

   real, allocatable :: x(:)
   ...
   allocate(x(100))
   ...

   x(1:100) = expr

This should require conformability even though the subscript
turns out to refer to the whole array.

   x = expr
   x(:) = expr

The above two could mean the same thing, even if that means
reallocation.

In fact, what would really be useful is a the following as
well as the above:

   x(5:) = expr

This reallocates if necessary and the new low-bound of the
array is 5.

   x(:10) = expr

This reallocates if necessary and the new upper bound of the
array is 10.  I suppose these last two would be too error prone
though and should not be allowed.  :-(


-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare