structure slicing question

[martymike]

Let's say I have the following:

type a
   type(other),dimension(:),allocatable :: def
endtype
type(a),dimension(:),allocatable :: abc

Assume that abc and it's def components are allocated correctly.

If I pass the following as an argument:

abc(1:x)%def(2)

(assuming x is within the allocated size of abc)

Can I expect to receive an dummy argument that meets this declaration:

type(other),dimension(:) :: dum

(assuming an explict interface) that would contain x elements?
i.e. an array of type "other" containing specifically
abc(1)%def(2)
abc(2)%def(2)
...
abc(x)%def(2)

This does not seem to work in IVF 15 update 4 (yeah, I know, get the latest version - believe me I'd like to).

[JVanB]

Well, there's this thing about

C918 (R911) There shall not be more than one part-ref with nonzero rank. A part-name to the right of a part-ref with nonzero rank shall not have the ALLOCATABLE or POINTER attribute.

I guess that may be the case because that would in general create an array section with variable stride, more like an array section with a vector subscript. The Fortran processor would have to pass the addresses of each element, not just their indices, or maybe do a copy-in copy-out which is in itself problematic in the standard.

Here's something I tried with parameterized derived types:

module M
   implicit none
   type other
      integer key
   end type other
   type a(len)
      integer, len :: len
      type(other) def(len)
   end type a
   contains
      subroutine S(dum)
         type(other), dimension(:) :: dum
         write(*,*) dum
      end subroutine S
end module M

program P
   use M
   implicit none
   type(a(:)), allocatable :: abc(:)
   integer i

   allocate(a(len=3) :: abc(4))
   abc(:)%def(2) = [(other(i),i=1,size(abc))]
   call S(abc(:)%def(2))
end program P

But my output with ifort 16.0 was

           1     7340141  1280592212     6881372

Is this a compiler bug?

[IanH]

It goes beyond just complications around a variable stride - such a designator would potentially permit elements of the one array to have different allocation/association status, dynamic type, length parameters, etc.

The issue in #2 is a PDT implementation bug, still present in current beta.  Otherwise type parameters are a good solution for this.