d必须禁止析构器吗

这里
按GC拥有对象构造类对象来,写这些.
准则:
论坛中看到了以下几个观点.
1,(这是复杂问题.)类没有析构器;应该叫终结者.
2,不要在类析构器中从GC分配内存.(如,writeln可能适合简单类型,但writefln或format则不行.)
3,因为可能已析构,不要使用类析构器中GC拥有成员.
一些事实:
1,不保证执行类析构器.这是程序员无法控制的.如,用户可传递以下命令行选项,而GC不会执行类析构器:

$ myprogram "--DRT-gcopt=cleanup:none" ...

(这样启动时,以下示例运行良好.)
2,即使GC执行了析构器的,也不知道何时准确执行.因此,重要任务交给类析构器(如关闭文件)是不行的.

恐怖:

我刚刚发现一个大问题.
上面两个准则(“不要使用类成员"和"不要分配”)错过重要的事实,对类结构成员也要递归这样.如,作为类成员的结构也不能在析构器中分配内存.
以下程序以core.exception.InvalidMemoryOperationError结束:

import std.format;

void closeConnection(string s) {
}

struct S {
  int id;

  ~this() {
    closeConnection(format!"%s关闭"(id));
  }
}

class C {
  S s;//类中构

  this(int id) {
    s = S(id);
  }

  // @disable ~this();//应禁止
}

void main() {
//只需1就可`显示`阿里环境下错误.
  enum N = 1;
  foreach (i; 0 .. N) {
    auto c = new C(i);
  }
}

问题在遗漏的指导方针:类应该@disable析构器.取消注释该行时,上面程序正常工作.
当然,应该加上@disable ~this();作为行为准则.
你怎么看?

不.类析构器用于清理非垃集资源.只要坚持这点,就可安全运行它们.

放入类的结构必须正确运行析构器,否则,会遇见可怕的不一致.
如,我不想在类中禁止RefCounted结构的析构.
如果关心在构 析构器中使用垃集,可用GC.inFinalizer检查.

我记得几年前,Andrei提议从语言中完全删除类析构器(或终结器,等等).有点极端,但反映了你的一般想法.
关于类析构器的一个观察是,如果不能清理资源(运行中不能依赖它,且禁止使用可能已收集的类引用),则*它们有何实际用途*,就没用.
类析构器的默认版无用,非默认时有用.
因此,如果用户使用--DRT-gcopt=cleanup:none运行程序,碰巧在GC分配类中有个RefCounted结构,则搞砸了?

便宜方法是使用像sprintf这样的@nogc方法?
:唔.也许准则应该是"析构器必须是@nogc".
我同意.

可观察到:
a),对所有类@disable ~this(),这样可免受其他编写良好结构成员析构器影响.一般,此选项需要该类的应在释放垃集内存前调用的清理函数.
b),在每个有可能在类中使用的构析构器中考虑GC.inFinalizer()(不一定都适用).
c),构中也不要在析构器中分配垃集内存.

struct S {
  int id;
  string closingMessage;       // <-- 很贵

  this(int id) {
    this.id = id;
    this.closingMessage = format!"%s关闭"(id);
  }

  ~this() {
    // 这里不分配,很好.
    closeConnection(closingMessage);
  }
}

用@nogc,如sprintf很便宜.