d的几个修复错误

这里
消除引用 中 域歧义.
推导std.typecons.Tuple.opBinary!"~"时,应为return scope,推导为了return ref.
需要正确修复这个问题.
1,把return-ref变成了return-scope.
2,除非return-scope,总是ref-return,里scope.

推导属性前,escape.d修改了TypeFunction,在FuncDecl的语义尾会替换掉,有复制存储类.而有些复制函数忘记了returnScope.
现在,可解锁12689了.
必须要改visit(CallExpe).新规则才能正常工作.你引入了STC.returnScope_和buildScopeRef,我使用它.按scope return重写return scope.

问题是有3种表示dip1000位的方法:
存储类,函数标志,域引用.
这向funcflags添加了isreturnscope来按存储类模仿returnScope行为.我还要考虑一下
简单引入isreturnscope,在FuncFlags中正确设置.
用isreturnscope在存储类中为本参设置returnScope参数.
在逃逸分析函数中为本参使用ScopeRef.
则可很好修复错误.
推导问题

---

纯函数可通过异常逃逸
对抛的强纯函数,不加域是有意义的.

---

除非使用-revert=dip1000,打印弃用消息

这里

因为如果只是强迫使用-preview=dip1000,那么简单的一行mars.d就可以了,但是如果是类似DIP25(我希望这样),那么也许"默认打开DIP1000"将是更准确描述.
但是,DIP1000仍然存在(多个)错误呢?

目的确实是做对DIP25所做的.我不认为"打开DIP1000"是准确的.目标是先用弃用消息来惹恼用户并强迫他们使用-revert让他们离开.一旦到位,实际上可默认打开它.

此PR是用户收到没有意义的弃用警告
-revert解决它.

-preview设计重点是降低编译器中代码的进入门槛,可淘汰并在野外尝试.如果在设计实际解决之前就开始将DIP1000设为默认值,那么我们既在-preview失败了,也接受了不安全代码,两种失败

-revert是有选择地禁用可能对某些用户具有侵入性的有效弃用类别的方法.不是启用不完整预览开关借口.

我们"只"必须修复错误.
DIP1000确实存在错误,但是,每个功能都存在.当我们可放心地说"现在是默认启用dip1000的时候了"时,安全何在?是否有任何需要先修复的明显漏洞?如果没有,我认为可以继续合并这个PR.

大问题,与这里

DIP1000允许实现既定目标:@safe引用计数.

我同意这是拦截器.DIP1000由于漏洞无法捕获的所有内存安全错误是一回事,而编译不是内存安全代码是另一件事.
还有这个

我懂了.我开始以为"如果用户不使用DIP1000,则打印弃用消息",而不是"用-preview=dip1000"开始弃用会出错构造.

dmd修复不难(#12989),这里,难的是不破坏火卫一(dlang/phobos#8214),这里.事实证明,修复区间中scope错误很麻烦.不能显式标记每个参数为scope,因为它是通用代码,因此希望依赖推导.如果没有纯和不抛,则很难推导域(问题20674,并且错误消息也没用:

如果用@safe注解放/干放,那么会导致__traits(compiles)或is(typeof())测试失败,给出无用错误.

那么合并PR时,我担心会发生什么?人们升级到dmd2.099后会遇到大量难以理解的scope弃用错误,其中许多错误是由于错误推导而导致的误报.他们想修复它们,但在论坛中询问如何修复之后,他们得到答案是"没人知道".因而我希望在将DIP1000设为默认值之前将其置于良好,有据可查的状态.

---

inout不隐含return

inout不应隐含return
带推断@safe的inout方法逃逸本地数据

删除return,可破坏现在代码.
意识到dip25已是默认,使当前不再吸引人,毕竟修复错误并保留增强功能更容易.
这个终于不阻塞了.