(j3.2006) Is this a constant expression?

[Malcolm Cohen]

It looks like it obeys the rules for a constant expression.

Yes, it's not very nice for the implementor, but then not much to do with 
derived-type parameters is.

>Not being a Fortran compiler developer, I don't know how objects of types with 
>length parameters are to be implemented.  I have heard remarks that they have 
>to be handled as if they had allocatable components.

No.  That would be one of the many possible implementation methods, one with the 
advantage that we already have the mechanisms in place for handling them.

>  If that's so, allowing this constant expression seems to be a bit of a 
> burden.

Yes, it is ugly.

>On the other hand, if the components' values are within the object instead of 
>the heap (or stack) with, offsets (or pointers) to components

If they are pointers, the ugliness is about the same as in the 
pseudo-allocatable implementation scheme.

>that follow ones whose sizes depend upon length parameters either stored in 
>hidden components such as "integer :: _offset_to_I", or computed from the type 
>parameters at each reference to such components, maybe allowing t(3)('abc',42) 
>as a constant expression is implementable.

Another obvious implementation method would be to store a parameter like this as 
a pointer to a chunk of bytecode that constructs the "right value".  No problems 
with copying that.

Alternatively programs that do this junk are just too complicated for the 
available resources - the standard does not specify a lower bound on the number 
of PDT named constants that can be defined... I favour zero.

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