Dear Dominique, That error is perfectly correct. Change the order of the assignment and the declaration for 'b' and you will see that all is well.
The matching of type parameter specification list follows the same rules as those of actual arguments, except that deferred and assumed expressions are allowed for PDTs. I am not convinced that I have deferred and assumed parameters fully sorted out yet. I suspect that I am too permissive. On the other hand entities declared in a module do not make any sense unless (i) All the LEN parameters are deferred; or (ii) The default initialization is somehow able to deal with variables in the specification expressions. I will have to ask one of the gurus how to do this. Cheers Paul On 12 September 2017 at 13:47, Dominique d'Humières <domi...@lps.ens.fr> wrote: > Dear Paul, > > I have been playing with the patch and found that the following variant of > the test for pr82168 > > module mod > implicit none > > integer, parameter :: dp = kind (0.0d0) > > type, public :: v(z, k) > integer, len :: z > integer, kind :: k = kind(0.0) > real(kind = k) :: e(z) > end type v > > end module mod > > program bug > use mod > implicit none > > type (v(2)) :: a > a%e = 1.0 > type (v(z=:, k=dp)) :: b > > end program bug > > gives the error > > pr82168_db_1.f90:23:24: > > type (v(z=:, k=dp)) :: b > 1 > Error: Unexpected data declaration statement at (1) > > I am also puzzled by the meaning of ‘z=:’ in the main program. Should not it > be restricted to be inside a procedure? > > Cheers, > > Dominique > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
