d的dip1000,2

@safe存在根本性设计缺陷,而DIP1000用来解决它.这不仅是为了新模型,而是要修复现有模型漏洞.如下在无DIP时编译,但DIP1000可检测到:

@safe ref int oops1()
{ int[5] arr;
  int[] slice = arr[];
  return slice[2];
}

@safe ref int oops2()
{ struct AnInt
  { int here;
    int* myAddress()
    { auto result = &here;
      return result;
    }
  }

  AnInt myInt;
  return *myInt.myAddress;
}

如果反对DIP1000,你必须:
1,应该放弃@safe从程序中消除未定义行为.我讨厌它.
2,假设简单禁止切片静态数组,并在@safe代码中,从成员函数引用结构成员地址.这会破坏很多代码,并迫使@safe代码放弃相当多性能.我也讨厌.
3,想出更好的检查方法.我不能.
我想提下,处理栈中数据时,只需要域.一般在堆上分配东西更实用,这样就不必与检查域作斗争.

仅传递给域参数的变量,可在栈上,而不是堆上分配,

void f(scope T);
T v = new T; // 可在栈上分配.
f(v);

是的,但在栈上分配是优化.因此,对@safe代码,只需让编译器管理所有内存,并在需要优化内存的地方添加提示.然后让编译器决定并报告布局是什么及为什么.
最后,域允许在@nogc函数中使用new.并且支持优化分配,因此域不仅适合静态分析器

这不是有效优化,因为DIP1000无法跟踪间接.因此,我可在子图中有与v相互连接的对象.
可优化时,LDC已经可以做到.DIP1000在这里没用.