@活是否使d像rust那样复杂?
要看.无论怎样,你可以在一个个函数上用借贷/物主,你不必重写/重设计.用垃集时没必要用@活.
import std;是自找麻烦.我一直反对,但几个月前未经我同意,仍然混进去了,1,因为他破坏代码,所以他阻止在标准库添加新模块.2,它让世上最快的编译器变成猪.主要就是名字冲突问题.
对特定变量用@活,我考虑了,但认为不方便广泛使用.
你用确定性的析构时,不必用垃集.
你可以用移动语义/无须垃集.是的.这类似对函数式编程的处理.在d你可以挨个逐渐的一个个函数上搞函数式/面向对象/@活函数,你想怎么玩都可以.
在rust中是不安全/不稳定,没有他们,秀很难工作.
本地导入,你本地导入标.文件,因此写就是上面的模块了,而不是标.标io里面的写了.这是域名解析工作了.如果放在模块域,则会出现两者的冲突.
标.文件与标.标io是域冲突,不是劫持.劫持是当两个都在同一作用域时添加重载,而这个重载偶然的比另一个模块的不相关重载的匹配更好.
秀有指定附加哪个函数参数生命期到返回类型的额外能力,而@活只取提供参数的最短生命期.秀的限定,其实没多大意义.dip1000打算成为核心功能,已经很成熟了,可以默认了.@活假定dip1000.dip1000针对所有d代码.dip1000增强@安全.
我的让@安全成为默认的dip失败了.把@活搞成默认肯定又是野蛮操作.
@活 @安全没意义.错.这只在垃集时正确.@安全并不处理分配/释放.也不管理你的容器内存,这应由用户来照顾,如通过包装.
@活既不是@安全的冗余,也不是其替代.他允许一堆与@系统/@安全/@信任独立的检查.尽管最好同@安全一起用.
如果,@活的最大问题是没法禁止,我认为这是@活的巨大成功.要理解当前的实现是原型,我希望我们能学习如何正确用它,就像D的函数式不能变成haskell一样,我不希望把@活搞得与秀一样.
c#风格更难重构.
它并没有引入新语法,懒的要点是不必用闭包语法来允许参数的懒求值.你上面的就是用闭包来代替懒.d在可变懒参数上已经这样用了.没人说不好.
不能再简化.在初化前,语义分析初化器.因此,x是未知的.你得这样声明:
int delegate(int) dg = (int x) { return x + 10; };不行,因为名字查找这个变量是全局的,你不能用@活.
我也说了,文档是不充分.否则,请加漏洞列表,如果不在,请加入漏洞列表.(d作者生活在漏洞列表中).
显示注解是不必要的.(d作者也认为秀的显式生命期注解没必要)
不是不能这样做,而是垃集与其他指针一样.添加垃集指针的说明,只是搞复杂,微软的管理c++搞过,不过好久没他们的声响了.
