[character(len=*) :: “abc”, “defgh” ]
would be more than enough a quality-of-life improvement imho (the majority of my use cases being setting parameter arrays at compile time, where performance is not an issue)
1 Like
This is actually a more general rule in the language: all elements of an array constructor must have the same type and type parameters, unless the constructor has a type specification (which includes the type parameters, such as the length).
[1, 2_8] ! not conformant
[integer(kind=kind(1)) :: 1, 2_8] ! conformant
[integer(kind=*) :: 1, 2_8] ! not conformant
You can also consider the case of a parameterized DT that has a len parameter.
The character length that has to be either consistent or specified is just one of the cases, and if it was changed, then it should be changed consistently for all the other cases (otherwise there would be soon some criticisms “why is it possible for this case and not for that case ?”)
1 Like
Yep, similarly we can’t mix 1- and 4- byte characters in the same array constructor -
Interesting case!! Well the same would apply: because the underlying concept is to have all elements of the array have the same memory size, the same idea would apply:
[ dt(len=*) :: … ]
Would create dt’s with the same max length parameter. Now the question shifts to “what do you pad memory with”, that is trivial in the character case but may not be trivial in the dt case (default initializer?)
It is common to see a user’s first user-defined type be a string type with a variable length string; just like almost everyone ends up creating or building an UPPER() and LOWER() function. All things considered making a string type intrinsic seems to avoid many of the pitfalls involved in changing the attributes of a CHARACTER variable. I think that should have happened instead of allowing existing CHARACTER variables to have allocatable length, given hindsight.
There appear to be at least two compilers already having an extension where the longest length is found so those implementations might be used to provide timing with compilers that do not to get some idea of the performance penalty. Unless it is negligible it would be hard to prove the difference is due to allowing this extension but it would be interesting none-the-less to do some performance timing differences between the compilers. that do and do not support the extension; although if those who do support it are much slower than those that do not a lot of other questions will need answered to be sure supporting the extension is the cause of the difference with the developers probably needed to answer that question, particularly for the proprietary compilers.
Note that several libraries including stdlib provide quite complete implementations of user-defined string types and operators.
1 Like
Two significant downsides of the allocatable character approach are that you cannot define parameters of that type and you cannot initialize variables of that type. For example, consider how one would normally define a fixed dictionary as a parameter array of strings; you can’t do that with an allocatable character variable. Presumably, an intrinsic type would have that capability.