Proposal: Better strings

Clive Page (see reference below) has a great summary of why we need better strings. I don't agree that VARYING_STRING should be part of the language. The pace of the language standardization process is too slow. I would prefer it if the language enabled third-party libraries to completely fill the gaps.

StringiFor, for example, is already better than ISO_VARYING_STRING ever was, but it can't completely replace CHARACTER since it can't be used in all contexts. I haven't fully though this through..but what if there was a way to tell the compiler to use a specified derived type as a string (and it would just automatically work in any context that a CHARACTER can currently be used). For example:

  type, use_as_string(str) :: my_string
    character(len=:),allocatable,private :: str = ''
  end type my_string

So, the use_as_string attribute indicates that when a my_string variable is used in place of a character variable, the str component is what is really being used. So:

  type(my_string) :: var

  var = 'string assignment works'
  var = var // 'as does concatenation'
  ilen = len_trim(var) ! etc...

Now, of course, these sorts of things can already be done by defining operators and overloading functions, etc. But what about:

  type(my_string) :: var

  write(var,'(I5)') i
  write(output_unit,'(A)') var
  
  var = var(1:3)  ! substrings work too

These are not currently possible with any third-party library. (Note: I think UDDTIO was supposed to help with I/O but it seems unsatisfactory to me).

To take this idea to its extreme limit, say, we had some function like this:

  subroutine input_string( c )
  character(len=*),intent(in) :: c
  subroutine input_string 

then maybe we could also use our new string type in this context as well:

  type(my_string) :: var
  call subroutine input_string( var )  ! works!

Note that this feature requires:

• the ability to set a default value for allocatable strings in types (see Issue #3).
• that all intrinsic routines that accept strings will auto-reallocate the deferred-length string to the correct size.
  (Both of these would be great features in their own right).

See also

• Clive Page, Improved String-handling in Fortran, Oct 1, 2015.

Start by reading this proposal alongside Issue #3, the StringiFor reference, and the cited Improved String-handling paper. Compare the requested derived-type string behavior with existing operator overloading and UDDTIO support. The proposal is not yet specific enough to define implementation files, tests, or a clear completion criterion.