d的@安全和dip1000

原文
我想知道他们@安全和dip1000的目标.确保整个程序的内存安全?
多字变量更新中的数据竞争怎么样?

@safe是的,但并不简单,因为main不是唯一可能的入口点,而且存在@trusted.
D目前:
必须标记共享数据为"shared".@safe代码无法访问shared数据(仅用-preview=nosharedaccess确保).如果想处理shared数据,要编写@system/@trusted代码并自己确保线程安全.
注意DIP1000不会使@safe更安全.它允许以前的@system代码成为@safe.如果写过这种代码,则DIP1000很不错.如果没有,DIP1000也不影响你.

如下,不用-dip1000或-ftransition=dip1000可编译,但不安全:

int[] global;

@safe
void f0(int[] val) {
    global = val;
}

@safe
void f1() {
  int[3] local = [1, 2, 3];
  f0(local);
}

DIP 1000会拒绝.

是的,八哥很多.如果八哥未通过-preview=dip1000表现出来,那么更不可能骂它.因为DIP1000最终将成为默认,问题就会消失.
反之亦然:-preview=dip1000有漏洞,没有开关就没有.但这些更可能得到修复,因为有人确实关心完成DIP1000.

d作者:尽管@safe不提供完全内存安全,但@live弥补了其他部分.
程序员可手动用锁来避免多字变量中的数据竞争.

pb:
嗯?我理解是即使没有@live,模编译器错误和错误使用@trusted,@safe代码应该是100%内存安全的.
添加所有权/借用系统所做的(或应做的),像DIP1000一样,可在@safe代码中,干以前需要在@system/@trusted中事情,比如手动释放内存.

今天实施的@safe的问题在按黑名单实现它.

我说"应该"和"模编译器错误"是有道理的.
但是,即使用白名单实现,仍有不应进而进白名单的错误.例如,最近几个修复-preview=dip1000的,正是针对这种类型错误.

是的,错误使用@trusted,@live仅在@系统/@安全中作为检查工具有点用.
@live未做所有权/借贷系统应做的事.我已经指出来,但大多数人似乎仍然假定如此.我不明白为什么.提议设计已公开了很久,很明显在@safe代码中几乎无用,因为@live就是个函数注解.
@live相比所有权/借贷,很肤浅,因而用处不大.

借用/检查系统和所有权是两件事.借用/检查器确保一次只一个可变访问或多个不变访问.
所有权与管理内存是相关的但完全不同的主题.Rust中臭名远扬的所有权系统因为移动语义,一次只允许一个所有权.
D中的借用/检查器,我还没完全理解它应解决什么问题.

我认为,在@safe中允许原始指针是基本错误.在@safe代码中,类似于C#/Java/其他,应完全不透明的管理内存.这样更容易,而D搞复杂了.

@live对编写@safe@nogc代码毫无帮助.
为了让@safe或@trusted代码依赖@live的所有权不变量,(例如,“非域指针拥有指向内存”),@safe代码不能违反这些不变量.由于@live的不变量只在@live函数中强制执行,并且允许@safe代码调用非@live函数,结果是,允许@safe代码违反@live不变量,因此@safe或@trusted代码不能依赖这些不变量.
要解决此问题,必须引入新规则,例如:
1,所有@safe函数也必须是@live.
2,@safe函数不能调用非@live函数.
当然,添加这样规则实际上会破坏每个现有D项目中的每个@safe函数,实践中完全不可行,这就是当前@live设计是死胡同的原因.