RFC legacy support for array constructor with different string lengths

[Daniel Kraft]

Dominique Dhumieres wrote:
>> Does it make sense to think about supporting it as legacy extension
>> (e.g. combined with printing a default warning)? 
> 
> Although I don't see it as a "legacy extension", but as a too strong constraint in the standard,
> why not? with a very low priority.  If it is supported, it's behavior should be clearly defined:
> for instance in
> 
> print *, ['YEAR', 'COMPCODE', 'RECEPTYPE', 'NCOLS', 'NROWS']
> 
> I assume that the extension makes sense only if the constructor uses the length of the longest
> string (less surprising effect), but it will probably simpler to implement if it uses the length
> of the first string.

What seems more of a problem (and maybe the reason for this constraint 
in the standard):  What if some entities in the constructor are not 
compile-time constants or have a compile-time known length?  For instance:

SUBROUTINE test (n, str)
   INTEGER :: n
   CHARACTER(len=n) :: str

   ...
   [ 'abc', 'defg', str ]
   ...

END SUBROUTINE test

In this case, should the char-len of the array be 4?  Should it be n? 
Or max (4, n)?  Here the constants can not be padded at compile time.

However, taking the longest constant character length, for instance, 
would not be a problem to implement.  I commit to do this (as I did the 
checking in the first place) if that's what we want for -std=gnu.

Daniel

-- 
Done:     Arc-Bar-Cav-Sam-Val-Wiz, Dwa-Elf-Gno-Hum-Orc, Law-Neu-Cha, Fem-Mal
To go:    Hea-Kni-Mon-Pri-Ran-Rog-Tou