Fortran抽象类型的最终过程

我可以向抽象类型添加

final

过程吗

假设最后的过程如下所示：

subroutine finalize(this)
   type(bin_tree_t), intent(inout) :: this

   deallocate(this%head)
end subroutine finalize

我的编译器（ifort 18.0.1）给出“错误#8313:类型（派生类型规范）不应指定抽象类型”。我明白了，但是最后一个子例程的伪参数不能是多态的

---

如果这是不可能的，那么这可能是标准委员会有意识的选择，还是仅仅是疏忽？

抽象类型不可能有最终的子例程。正如您所注意到的，这样一个子例程的参数不能是多态的，我们不能用

type（spec）

实例化抽象类型

当一个对象被最终确定时，最后选择的子例程是一个参数类型为待最终确定对象的动态类型的子例程。任何对象都不能具有动态类型或抽象类型。最终子例程不会被继承（也可能不会被重写）

我可以想象这样的用例：抽象类型的最终子例程会很好。实际上，我们希望抽象类型执行的任何终结都应该由扩展类型完成。请注意，抽象父级的可终结组件仍将被终结

我无法评论标准委员会的想法，但这些案例似乎没有比我们现在所拥有的简单的定稿规范更有价值

---

我说过，最后一个子例程的参数不能是多态的。这是Fortran 2008标准的C480。这是一个非常合理的问题，可以问“允许多态性论证会导致什么问题？”

正如我们所做的那样，终结过程并没有在通用解析、重写或继承方面表示为实体选择的最终子例程。选择是“如果动态类型有合适的子例程，就使用它”。相反，如果允许多态参数：“如果动态类型有合适的子例程，则接受它；如果没有，则遍历父类型…”。后一个概念在其他地方并不多见

请注意，一旦扩展类型被最终确定，父类型即被最终确定（即使该扩展类型没有相应的最终子例程）

---

总之，在我看来，不存在禁止抽象类型的最终子例程的积极愿望，但允许它们的成本太高了。目前的方法定义非常简单。最终定稿是否可以用另一种方式编写？对唉，我们需要有更详细的知识的人告诉我们为什么选择这种方式。

您自己回答了技术原因。你应该问委员会的人关于原因的问题，也许史蒂文·莱昂内尔可以告诉我们一些事情，他不时来这里。我想你也不认为这是可能的。这让我很惊讶，所以我想我可能错过了什么。也许用例并不多，是的。但我还是错过了一些东西。在gfortran开始完全支持FINAL过程之前，我不会开始使用FINAL过程。良好的背景信息，但无法解释为什么FINAL子例程传递的伪参数不能是多态的（即，

class（spec），intent（XX）：：this

）。如果标准允许这样做，会造成什么问题？这有点杂乱无章，但我希望它能适当扩展。如果你觉得有什么不清楚，请告诉我。（我稍后还会重新起草这篇文章。）你至少在一些方面做出了重大贡献。首先，你帮助我更清楚地阐述了这个问题（见我上面的评论）。其次，你（和弗拉基米尔F）证实了我的怀疑，即答案即使是专家也不明显。