原文

拉兹万

预览开关

Razvan一直在查看-preview=nosharedaccess报告的问题,但只从atila那里找到了少数几个.表明或有个没有很多错误的良好实现,或它没有大量使用它.阿蒂拉认为没人用它.
Razvan指出,atila报告的一个错误是试实例化共享类会导致错误.
如果不工作,则有其他问题.他想知道如何使预览成为默认值.除了等待人们使用并报告错误外,还能做什么.
atila说他一直让Phobos和DRuntime用它编译,然后一旦这样做了,就可在配音包上试一下.他说他遇见了太多噪音,决定等到修复报告的错误后再报告更多.

Iain建议应该有个默认打开所有预览开关的管道.Dennis指出,对破坏的预览开关,有问题.

Mathias问好的预览测试会如何.他试它们时,遇见了nosharedaccess和rvaluerefparam不管用的问题,然后他放弃了预览.
atila不知道好的预览测试,但正在努力浏览预览并决定设置它们为默认值或废弃它,尤其是那些已有多年的测试,这样就不会有问题.我建议,在构建时,制定一项定期审查预览的策略.

Razvan说,主要问题是预览开关是否达到了期望目的.它们的目的是为了,让人们可在新功能正式成为语言的一部分之前对它测试,但,似乎很少使用它们.
在合并新功能到编译器版本之前,应该有个不同机制来确保经过测试,然后一旦合并它们就可用了.在他看来,预览开关是功能的坟墓.

我说这似乎是个沟通问题.现在,只是在预览开关后面抛一个功能,除此外闲着.我建议提出分阶段的过程,激励人们使用预览.

罗伯特更激进.对想要合并新功能以测试它的人都应该负责,用新的编译器版本测试dub包的新功能,然后调查错误.前30个等应,在用和不用预览开关都能编译.阿蒂拉同意了.

马蒂亚斯说,预览想法很好,可工作.只需要认真对待它.他说他同意罗伯特.当他实现-preview=in时,他完全按Robert的建议做了,测试允许默认.

他默认启用它,然后检查它破坏了什么.一般,预览是使用半生不熟代码实现的,不会测试是否有效.需要确保,实现预览版的人员正确干活.

Walter说可为每个预览功能提交拉取请求,来默认打开它,但不必合并它们.来确保它通过(测试几个配音包的)BuildKite运行,就有中断代码的链接.然后,联系了破坏了的包的维护者,帮助升级他们的代码.

最后,决定让Razvan和atila收集所有预览开关问题,可在未来的会议上决定他们的命运.

@system和纯

Razvan说,偶尔会出现@system和纯代码的问题.他说,试做如分配而不初化内存的系统级的事情,可能会与纯冲突,而在@safe代码中,纯一般是兼容的.

但可做一些事情,比如在@safe代码中,void初化栈变量再返回它,现在两个概念冲突了.他期待安全和DIP1000成为默认,他想知道是否可强制不必同时有安全和纯.

这触发了侧面讨论,即为什么会在不初化内存,就分配内存等.罗伯特说,无论应不应该这样做,语言都允许这样做.或语言应阻止它,或它应工作,或给出有用错误消息.仅告诉人们不要这样是没用的.

Razvan以std.experimental.allocator为例.像Mallocator此类,不可能是纯的,但在纯代码中仍需要使用这种分配器.Walter说,从根本上说,存储分配器不可能是纯的,语言的行为是正确的.

如果想从纯代码调用分配器,则必须在代码中做些肮脏的事情.这是可以的.语言不应默认支持使存储分配器为纯.它正在工作,说因为你在改变状态,因此你不能这样做.

所以必须有肮脏转换来伪造它.D支持系统代码的原因是,可在必要时做些肮脏工作.D不支持逻辑常,因为逻辑常不是常.

这不是强制的.这是一个功能.如果想要逻辑常,你必须做些肮脏工作,这是合适的.

Walter还表示,在纯代码中是否应允许void初化是另一个问题.void初化int,并返回它,不是纯的,是吗?所以也许,在纯代码中,应禁止void初化.这是个合理的主张.

atila同意并补充说,系统调用本质不是纯的.他们不纯不重要,否则就是撒谎.沃尔特同意了.系统调用一般会更改系统.

编译器无法区分.也许有些真是纯的,可单独标记它们.但总之,只需要欺骗它.他喜欢D的常和纯的概念是严格的.

丹尼斯有个"疯狂命题",不确定自己是否同意:是否去掉纯,人们似乎不喜欢属性,他没有遇见人说"哇,D有纯,它节约了我所有的代码".他的意义?丹尼斯说他也使用纯,但从不觉得自己真需要它.

atila说,在Symmetry,因为人们在应该用纯时而不用纯,就会缺少纯带来的功能.他引用了SIL项目(Symmetry内部DSL)的一个示例:

查找函数名的功能,涉及调用函数并取其输出,你不会想调用格式化你硬盘的函数.如果标记D函数为纯函数,那么在SIL中也是纯函数,因此此时是可调用的.

Walter指出,纯函数也可毫无风险地成为多线程函数.他们不与其他东西互动,在自己的岛屿上生活.atila说,也可从纯函数初化不变的东西,这也非常方便.

Robert说,在Symmetry的D代码中,有些函数是纯的,因为标记它们很简单.其他都不是纯或不变的.对每个示例,都可找到一个反例.

沃尔特说纯可能很难使用,但应该是一个目标.编程中的一个好原则是,函数中一切都应该通过前门.如果能让函数为纯,就对了.你知道:它没有副作用,它是线安的等等.

伊恩

目前,他有几个问题需要解决.运行测试包时,他缺少一些模板符号,可能是因为模板发布策略的变化.影响他的原因是,他使用单独编译来构建DRuntime和Phobos.他还没有找到时间解决该问题.

Martin查询模板发射错误出现在哪个前端版本,及是DRuntime还是Phobos显示它们.伊恩说,它在一月份之后进入了标准库主线.因为链接时故障,返回为未解决.他觉得他可能是唯一使用单独编译来构建DRuntime和Phobos的人.

Martin说他现在只使用单独编译来单元测试,否则内存使用量会爆炸式增长.Iain说他也单独编译单元测试.单独编译每个单元测试非常有帮助,因为可在make端增强并行性,且一个失败的单元测试模块不会阻止其他模块的测试.

Iain说,codegen胶水也有了一些变化,它们一直在引入回归.因为这样的更改是在dmd后端,所以他可弄清如何实现的,及需要做什么来为GDC实现它.
然后,一旦他这样做了,他就要花15分钟弄清如何打破它.然后编写的第一个测试,就有运行时破坏.

GDC文档现已在gnu.org在线.他说,可能还有些空白需要补充.

他一直在支持GCC的C++开发者移植D到他们的平台上.他们提出了一些观点,其中一些可很容易地解释,如,结构和类间的区别,但其他观点更有趣.
不移植的原因有,仍为只包含字段而不包含函数的extern(C++)类生成虚函数表.

另一个是D禁止标识符号中使用破折号,因此如foo-bar.d不能用作模块名,而C++中可以#include foo-bar.h.
他们发现此文件名约束是非常令人惊讶的.

Dennis指出,文件名中的破折号出现在ImportC中,特别是在试导入Wayland标头时.

沃尔特说你只需为它写个包装器.创建另一个只#includes有问题头文件的头文件,或把有问题文件放在命令行上并使用-mv重命名它.

他不认为这是个重大问题.Iain说,你只是在围绕一个对你不利编译器工作.沃尔特说,这两个处理方式都不繁重,所以不想为此改变语言.

我注意到ImportC背后的要点在于它"只是工作".这就是目标.沃尔特同意了.我说过,需要"正常工作"方面的人并不关心这两个解决方法.

沃尔特说应该记录下来.阿蒂拉说他甚至不知道有-mv.Martin补充说,如果正在处理小组文件,包装器解决方法很好,但如果它是带有大量有问题的头文件名的大型代码基,它就不管用.

沃尔特说,他对ImportC有很多问题,这是个低优先级,且不是阻碍因素.ImportC不编译标准头文件.这是个障碍,因为没有解决方法,这应该有优先级.

文件名问题有解决方法,所以不是阻碍.无论如何,ImportC都需要有效标识模块名.也许像pragma(mangle)会有帮助.

Iain突然想到:是否有一份如何从C++思维方式编写D代码的文档.Walter说应该看看,与C++对接页.这是一份迫切需要现代化的旧文档.

Dennis和Mathias都在聊天中链接到上面链接,Mathias建议,把它作为更好的关于语言功能的对接C++页.

我提到了一本名为<C++的Java书>的书.如果对两者都有深入了解的人有时间写一本"C++的D编程"的书可能会很好.
Walter认为D在与C++对接时,可能有Java相同的问题,因此可作为D版本需要涵盖内容的指南.

阿蒂拉

atila报告说,因为在与C#交互时遇见了一些问题,他在Symmetry上就DIP1008有一些内部讨论.因为D和C#各有一个GC,因此它们不想只是从一个GC分配内存转移到另一个,因此到处使用了@nogc.
他们遇见了异常问题.DIP1008对他们不管用,最终不得不手动处理引用计数.问题根源在于他们正在与C#交互,而使用的D库很古怪,所以不确定是否有可操作的东西.

马丁补充说,如果对抛式,跳过检查@nogc,他们会很高兴.特别是最近在生成栈跟踪中,更改为不使用GC.他想实验看看,是否帮助Symmetry中的用例.

atila最近一直在和Iain谈论ImportC,稍后需要和Walter谈谈.他也一直在和马蒂亚斯谈论配音.atila认为把他在雷鬼中的工作,放在配音中是有意义的.大多数人都会使用dub,所以把雷鬼功能放在那里是有意义的.

他重复说,他一直在通过预览开关来决定他们的命运.如果它们是新的,那很好,但是像rvaluerefparam和nosharedaccess这样的已存在很久的东西,需要成为默认值或删除.他开始试用nosharedaccess编译,并立即遇见了一堆错误.

最后,他问大家对把Phobos放入dmd/druntime单独仓库有何看法.伊恩说,对他而言,DRuntime和标准库都是一回事.
马蒂亚斯对此表示支持.罗伯特说,如果这样,他要做的第一件事就是用标准库版本替换一些过滤实例,因为应该在DMD中使用标准库.(注意,此处没有做出最终决定).

沃尔特

独立组件

最新,已可以使用独立组件.

导入C

ImportC正在慢慢磨合.首要任务是在所有平台上编译所有标准头文件.用不同编译器,试编译了各个平台上的许多系统.h文件,但失败得很惨,每个文件都以独特的方式失败.
如果可编辑这些文件,则很容易修复,但当然,他不能.因此,只能试提出创造性的解决方法.这是高优先级,在ImportC失败时,通过导入系统头文件来使用ImportC的人都会退出,并标记它为不可用.

CTFE中的模板降级

他发现的一个问题是,语义例程带多个构造并按模板降级它们.即使在CTFE中运行时,也会这样.这些模板会产生很多膨胀.

在CTFE中,它不应降级.CTFE发现按高级代码解释更容易.经过调查,他发现CTFE反转了一些降级,以便可解释它们.

如果在CTFE中工作,比如连接数组,你会遭受大量不可见的模板膨胀.这需要解决.他大约完成了一半.

他正在查看所有降级并重写它们,这样在CTFE中,不会降级.他想这是减少内存消耗和CTFE速度慢问题的又一步.他还想消除解释器中出现的"展开降级".

Iain指出,在重写_d_newclass运行时勾挂为模板的PR中,他注意到了Walter刚描述的相同内容.他让作者更改,而不是降级>不降级>重新降级,在叫降级的字段中放入重写,而保持原节点不变.通过CTFE时,只需专门在该节点上工作.

然后,一旦生成代码,你点击该节点并进入降级字段.Walter说,还没有完成其他重写,但TeodorDutu和Razvan计划返回并改变它们(这是为此工作的一个示例).沃尔特说,这也允许是在BetterC中更广泛地使用CTFE的一大胜利.

我

我建议将季度分成两个单独的会议:每月第一个星期五的季度会议供工业人参加,然后在下个星期五举行月度例会.大家都同意了.

马丁

马丁说,他一直忙于ldc,因为他必须赶上最新的DMD版本.这总是好的,因为他对未经DMD测试的平台有CI测试覆盖率,因此他一如既往地发现了些小回归.这些已在DMD2.102.2中修复.

他发现了一些与降级模板运行时勾挂相关的回归.如,数组连接的新降级表明CTFE串连接不适合WASM等目标,因为新降级要求一些标准的C绑定.幸好,修复起来很简单.一般,这些降级需要在这方面仔细设计.

atila想知道是否可添加LDC到CI中,以便可提前抓此东西.马丁说没办法.

他对Iain提到的新的"降级"字段感到非常高兴.他们一直思考,是否有降级更高级的AST到实际代码生成AST的第四个语义阶段,这似乎是朝着该方向迈出的一步.或至少等等.

从ldc胶水层来看,2.102版本中更大变化之一是比较向量.现在它们基于前端AST结果,生成向量掩码.他很惊讶,因为更改没有进入更改日志.这对浮点向量,是个痛苦.

按位操作符不适合浮点向量,因此他不得不再按按位操作的整数向量,来解释转换它.在这方面,GDC和LDC按再解释转换(C++重转)来转换向量(如,转换float4向量为int4),但对DMD,这只是个转换.

这是个重要的区别.另一件事是,目前在DMD或GDC中不能比较标识,因为在前端会阻止它,但LDC确实支持这些,并降级它们来产生标量布尔值.

马蒂亚斯

Mathias想通过dub来克服潜在依赖项带来的错误.依赖项是子配置的一部分,但启用了不同的子配置时,根本不应拉入该依赖项.是报道最多的配音问题.
如,目前不能有仅测试依赖项,因为这会污染其他所有内容.他一直在研究该问题,及最近与阿蒂拉讨论所推动的一些速度改进.

另一件事是他想默认启用-preview=in.他对它的工作方式相当满意.他在生产中已用它多年了,它完全按期望工作.
为了简化过渡,还缺少了一些小东西.一个是在函数字面上推导存储类,这是他在会议前几天修复的一个错误.他仍在试找出一些事情的最佳弃用路径,但越来越接近可启用该功能的状态.

他说他想在栈跟踪中看到高亮,所以他一直在研究dmangler,以便可直接从demangler上高亮D符号.如果它不管用,那么它就不管用,但它肯定会使demangler代码更好.