他们认为__metadata字段不能从外部访问实现引用计数的对象.这样,强纯函数不会改变__metadata字段,因此可基于纯来优化(除了释放函数).
析构器在限定符上遇到与postblits相同问题.如果可调用不变析构器,我会感到惊讶.加上不能重载析构器,这更糟.
然而,为了支持不变分配器,确实要考虑如何分配和释放.
这里问题是把高级(纯)与低级(分配/释放)混为一谈了.后一类本质上不是纯的,因为它修改了操作系统的数据结构,可按系统|而不是不安全对待它们,且因为需要操作系统帮助.
现在,该函数即使签名是强纯,最多应是弱纯的(这就是可变函数).
一种方法是无论签名如何,把@系统/@trusted纯函数视为弱纯函数.构造器/析构器最多是弱纯.如果函数是@safe且纯的,则应分析签名来确定是强纯还是弱纯.此外,从另一语言调用函数最多为@trusted.这样,@trusted充当优化阻止程序.
在开发分配器时.我在思考映射内存是否应按纯对待.
最终认为,已按纯定义new形式的映射内存.我不同意这样,但它一直是.
因此,我把映射内存归类为一组"神"功能.因此,修改执行环境但不修改执行逻辑,可当作纯的.
:他们认为__metadata字段不能从外部访问实现引用计数的对象
不是真的,如,只是公开它的指针.不必有可见性规则.
注意,引用计数不是唯一用例.如懒初化等.
:强纯函数不会改变__metadata字段.
并不真地.
:因此可基于纯来优化(除了释放函数).
那是倒退.基于纯优化决定了可对__metadata字段做什么.因为不应在那干活,所以它应是@系统,应由程序员而不是编译器保证.这是低级特征.
:(除了释放函数)
注意,必须专门标记从析构器中使用的函数.
:析构器在限定符上遇到与postblits相同问题.如果可调用不变析构器,我会感到惊讶.加上不能重载析构器,这更糟.
好吧,如果破坏不变对象会怎样.需要有语言规则允许内存暂时不变,否则引用计数方案对不变内存不适用.
:这里问题是把高级(纯)与低级(分配/释放)混为一谈了.后一类本质上不是纯的,因为它修改了操作系统的数据结构,可按系统|而不是不安全对待它们,且因为需要操作系统帮助.
这并不是混淆,而是你在低级操作中实现了高级概念.这没问题,总是这样工作的.
它们是不安全的,因为需要按某种方式表现才能将它们视为"纯".
我认为与弱纯和强纯没太大关系.这是不同领域.
@trusted或@系统并不阻止优化.这是正交语言设计.
:在开发分配器时.我在思考映射内存是否应按纯对待.
:最终认为,已按纯定义new形式的映射内存.我不同意这样,但它一直是.
那只是错误的抽象级别.显然,创建新值应是纯的,可在基本上所有纯函数式编程语言中创建任意树结构.它一般是此类代码运行方式的核心.
D中"纯"的理由是可与此类语言竞争.
分配/映射内存自身是否应是"纯"是有争议的.如果分配失败不是致命的,或返回可访问的未初化内存,则当然不是"纯"的.
然而,new(映射内存+初化+构造)并未为此设置先例,它更高级.
:因此,我把映射内存归类为一组"神"功能.因此,修改执行环境但不修改执行逻辑,可当作纯的.
只要不泄漏分配器状态到可观察的行为中,分配加构造就没有问题.(如,窥探指针位应是不纯的).始终要特殊对待释放.
令我震惊的是,该DIP与正在最后审查的DIP1035@系统中描述的变量类似.完全可以合并__metadata描述特征与DIP中的@系统变量特征.
效果是,除了不能在@safe代码中访问它们,可对@系统变量做任何事情,这正是重点.可违反类型系统.你有完全的自由.就是这样.
我想缺点是你可能不希望拥有所有自由.但是我正在考虑希望@系统变量不变.@系统|__metadata这两个DIP的全部意义在于@系统|__meta数据是可变的.(对DIP1035,可变性很危险,必须标记为@系统.__metadata整个要点是强制可变性绕过类型系统.)
:上行.
不完全正确.DIP1035还指定按@系统推导在@safe代码中禁止初始值的变量,对可变和不变变量同样适用.
所以,指向未定义内存已经够危险了,但它仍然需要不变保护的,因为一些@系统程序员可能希望它指向别的,我们禁止这样,因为禁止@系统程序员这样做吗?
即,如果@系统一开始就足够危险,那么使它可变,会增加了多少额外的危险?
并不增加额外危险,但是在类型系统中,让变量@系统属性像如此交互是不明显的特例.如DIP1035目前提及,不变,与他们相互独立.
