Yes it is.
But so does every single derived type in the spirit of the ones shown by @rwmsu, @RonShepard, or even Michael Metcalf in 1984:
! @rwmsu's string
Type DLstring_t
Character(LEN=:), allocatable, :: aString
End Type
! Ron's string type
type string_type
character(:), allocatable :: s
end type string_type
! Metcalf's string
TYPE String(Maxlen)
INTEGER :: Length
CHARACTER(LEN=Maxlen) :: String_data
END TYPE String
I bet almost any seasoned Fortran programmer has used his own one at some point.
But for serious work it’s not just the basic type which is needed. You need all the procedures that belong together with it and are a pain to write and debug. On top of the procedures you need the documentation (personally, I’m not yet satisfied with our stdlib one) to go along with them and the instructions how to build the software using a plethora of different build systems.
All of these problems go away when something is shipped with the compiler.
Addendum: Essentially we encounter the same problem as Tim Mattson spoke of for parallel programming languages:
- the standards community has failed us by not standardizing a string type (be it intrinsic - better, or derived - worse); if it didn’t pass in 2000 why would it pass now?
- as the application developer community we have failed ourselves, by not joining forces earlier and figuring out ways to reliably distribute high-quality Fortran modules including for strings
So the two solutions to the problem are either stronger committee involvement and pressure on the compiler vendors, or stronger collaboration in the Fortran community. Next time someone asks how to get an array of strings, recommend them a central solution like stdlib
and not your own homebrew.