Fortran 在子例程调用中使用用户定义的派生类型赋值

我想通过编写一个更具python风格的字符串类型来克服fortran中糟糕且不直观的字符串处理，但我遇到了一个关于派生类型（重载）赋值的平均问题。 主类型应该如下所示

TYPE t_string
    CHARACTER(:), ALLOCATABLE :: str
  contains
    ...
END TYPE t_string

它在派生类型程序中具有强大的功能。当然，新的字符串类型应该尽可能与内在的

字符（len=*）

类型区分开来。特别是我想使用内部例程（使用

字符

类型），而不需要任何额外的类型转换。因此，我在

类（t_string）

和

字符（len=*）

之间定义了赋值运算符。例如，

open

ing使用新类型的文件应如下所示：

type(t_string) :: filename
filename = '...'
open(file = filename, ...)
!         ^ assignment here

由于

t_string

和

字符（len=*）

之间存在赋值

file=filename

，因此调用

open

应该没有问题。但是由于类型不匹配，我得到了一个错误

我想问题是，子程序调用中的赋值实际上不是赋值，而是某种语法约定

• 有没有办法解决这个问题
• “子程序赋值”不是真实赋值的原因是什么（就fortran语言的设计而言）
• 我不想调用

  open（file=filename%str，…）

这里是一个mwe：

MODULE m_string
  IMPLICIT NONE
  SAVE

  INTERFACE ASSIGNMENT(=)
     MODULE PROCEDURE  ::  string_operator_equal_s, string_operator_equal_c
  END INTERFACE ASSIGNMENT(=)

  TYPE t_string
     CHARACTER(:), ALLOCATABLE :: str
  END TYPE t_string

CONTAINS

  ELEMENTAL SUBROUTINE string_operator_equal_s(lhs,rhs)
    IMPLICIT NONE
    CLASS(t_string),  INTENT(inout) ::  lhs
    CLASS(t_string),  INTENT(in)    ::  rhs
    lhs%str = rhs%str
  END SUBROUTINE string_operator_equal_s

  ELEMENTAL SUBROUTINE string_operator_equal_c(lhs,rhs)
    IMPLICIT NONE
    CLASS(t_string),  INTENT(inout) ::  lhs
    CHARACTER(len=*), INTENT(in)    ::  rhs
    lhs%str = rhs
  END SUBROUTINE string_operator_equal_c

  SUBROUTINE routine(char)
    CHARACTER(len=*) ::  char
  END SUBROUTINE routine

END MODULE m_string


PROGRAM test
  USE m_string
  TYPE(t_string)    ::  str
  CHARACTER(len=10) ::  char
  CALL routine(char)            ! no error
  CALL routine(char=str)        ! error: #6633: The type of the actual argument differs from the type of the dummy argument.   [STR]
END PROGRAM test

因为在t_字符串和字符（len=*）之间有一个赋值file=filename，所以调用open应该没有问题

没有此类任务。您仅使用说明符名称来指定要传递的语句的参数（类似于Python中的关键字/命名参数，但不同）

open

实际上不是一个过程，它是一个语句，但它也有其“参数”（说明符），可以通过名称来区分

---

因此，不得调用派生赋值。你必须自己转换成

字符。
虽然链接的问题谈到
iostat
说明符，但
文件的说明符也一样。
：这是说明符，不是参数关键字，当然也不是赋值过程。@francescalus我不相信这确实是重复的。@VladimirF，问题已经解决了“子程序调用中的赋值实际上不是赋值，只是一些语法约定”，链接的问题是相同的（错误的）概念。（还有其他问题也涉及关键字参数。）如果问题是直接关于“如何使用非字符类型作为文件名？”？“那么我同意这将是一个不同的问题。当然你可以重新开始这个问题，但是你的回答范围不能说服我这么做，我想是的。多可怜的孩子啊。你有没有什么想法来解决这个问题，保持使用这个字符串类的工作量低？从理论上讲，这可以添加到未来的标准中吗？或者，将“子程序赋值”/“子程序名称标识”变为真正的赋值是否会产生副作用？有人说，在某个时候，可以将泛型添加到fortran中，这可以解决这个问题（以及许多其他问题）。但是，不要期望这一点很快被标准接受，或者在这之后很长一段时间内看到编译器支持……Gonestly，我不认为泛型在这个特定问题上有什么帮助。@VladimirF我（事后看来过于乐观）假设，如果添加泛型，内部语句将被更新以使用它们。因此
open
的
file
参数将接受扩展
character（*）
或具有
character（*）
特征或类似特征的任何类型。@veryreverie
open
不是函数。您可以在Fortran 90及更高版本中重载内部函数。但是
open
是一种声明。