d的11月会议

原文

马丁

Martin告诉下个LDC版本会晚一点发布,他没有太多时间,仍然需要解决一些合并DMD和DRRuntime仓库的细节.
他刚测试了2.101.0RC1的对称代码基.目前还不算太差,但很难确定,因为需要更新几个dub包.一个可见好处是,它发现了一些与复制构造器相关的现有八哥.还发现了一个要提交的回归.
除此外,他祝贺Dennis在推导函数方面做出了些新的诊断,表明,如,不再需要手动找出,因函数中的哪一行,而推导函数为@系统而不是@安全.

目前,测试的对称(Symmetry)项目上,最新配音版本没发现回归.这是很好进步.新的彩色输出也非常好.

Petar问Martin是否计划整合LLVM15到下个版本中,或懒到下个版本中,Martin说NicholasWilson和其他人已准备迁移到LLVM15,根据测试,LLVM15应工作.但是在Martin用LLVM15运行所有测试前,还有些工作要做.

首先,需要为所有目标更新LLVM的LDC分支为LLVM15.然后,他需要克服通过GitHub动作测试普通LLVM的问题,因为LLVM团队已停止生产某些GitHub工件.现在还有问题.

拉兹万

过去一个月,拉兹万一直在研究noreturn实现,他已修复了一些,但仍有五六个报告的八哥没有修复.他遇见了肯定是后端有时无法识别noreturn的障碍.
Martin说,前端懒到后端的所有东西都会影响胶水层,如果未在前端处理它并降级到其他构造,noreturn是个不幸.
如,显然不能有noreturn全局变量,但是它们仍然在AST中,所以胶水层要处理它们.在LDC中,用一个空字节赋值它们,但这会在调试信息中引起一个问题:它需要一个类型,但是给它什么类型呢?
最好是AST中没有noreturn,而是把它们降级到其他构造中.所有其他编译器都要复制DMD后端中修复的所有问题.

沃尔特同意了.noreturn根本不应进入后端.在决定如何解决它前,要返回并查看后端中已有内容.

接着,Razvan报告说,他一直在找为函数实现抛属性的公关.问题是它有nothrow时,可能会中断用getAttributes属性的代码.

Walter说编译器内部应该按缺少nothrow而不是按单独属性对待throw.唯一目的是关闭nothrow,因此最好是不必更改用getAttributes的代码.
它不像是三态的@安全/@信任/@系统.二元nothrow/throw状态,只需关心函数是否为nothrow.

这里,安德烈提起了过去属性(真)及属性(假),沃尔特说,语法很笨拙,很容易用抛关掉nothrow,因为它已是关键词了.
Petar提出纯(pure)及@nogc.触发了属性代数,属性汤,相互禁止的正负属性,属性推导,循环依赖等长时间讨论.

最后,丹尼斯给出了他的观点,并提及过去提出的另一个建议:用默认(default)关键字来为非模板,未注解函数创建一组可"重置"函数属性状态的默认属性.Walter认为用默认来重置状态是个很好主意,应该在实现抛属性前考虑它.丹尼斯提交了一份.

接着,Razvan提供了一些,在嵌套在其他式中时,在被调而不是调用者环境中,与求值__FUNCTION__和__FILE__有关的八哥列表问题的背景知识.

他有个要沃尔特决定的公关.Walter随后反馈了下代码,尚未对总体方法发表意见.

最后,拉兹万问了下移动构造器DIP,这里的状态,Max说他有一段时间未在上面工作了,但他需要根据Weka的关于"最后使用"推导的反馈来修改.
Martin建议语法和作为引入语言特性的移动构造器,应在最后使用后解耦.因为后者允许编译器不必让用户,在指定时调用库函数,而是自动移动的优化.他希望比库方法更简单且性能更高的内置移动和转发.

马克斯

Max拿来了简化D语法(弃用尾部小数点这里,禁止令牌序列尾部中添加注解这里,不再支持小八进制这里)的三个DIP.需要这些DIP吗?马丁认为不想.沃尔特也不确定.

Dennis提供了一些背景知识(Garret已为D实现了Treesitter语法,由此产生这些DIP),并提出了更大的问题:
降低词汇复杂性的价值?过去否决了类似修改建议.一方面,一些用户不希望破坏.另一方面,工具开发者感到沮丧,因为很丑陋.简化语言是在愿景文档中.是否值得清理下来制作更简单的词汇图?

Walter认为这是值得的.但需要在逐个案例基础上考虑.Iain建议此更改需要弃用周期.删除-transition=complex用了10年,并仍开启20个版本周期的弃用.

Max接着问是否弃用现有语法,现在有两个Treesitter语法,用从Treesitter语法生成的机器可读语法来代替它,Max认为Garret的实现禁止编译器做某些语法错误的事情.

Walter指出,如果人们为D创建了其他语法,这对他们来说是个重大失败.如果不是机器可读的,那么应该修复它.Dennis指出,弗拉基米尔已修复他的一些Treesitter语法,来后向移植到了官方语法上.

丹尼斯

丹尼斯先提出的第一个问题,是在实现命名参数时遇见的.dip建议,重定义语法中参数列表(ArgumentList),来用命名参数(NamedArgument)代替赋值式(AssignExpression)(现在是命名参数的部分定义).
但是有时不需要命名参数(如用户定义属性(UserDefinedAttribute),Pragma,CaseStatement),此时用参数列表.
他想知道是否应该把命名参数从解析移动到语义中.Walter建议定义在命名参数地方使用新的命名参数列表,并在其他地方,继续使用参数列表.他说应该尽早发现错误,所以最好在解析过程中发现命名参数错误.Dennis说他会提交一份PR来修改DIP.

接着,Dennis提出了稳定和主分支间区别,
可总结为:没有硬性规定,只有低风险才应该进入稳定分支,但是否低风险是个主观判断.

这次讨论产生了两个结果,一个是Martin和Iain同意在发布DMD前,对β和发布候选阶段,应该有更多时间,另一个是应该安装1个GitHub动作来自动合并所有到稳定的提交进主分支.

我

我在编辑和发布剩余4个视频.
然后通知了下dip1044的作者,推导枚举类型.

安德烈

安德烈问拉兹万关于原型对象DIP,这里.Razvan说AdamRuppe在DIP的拉取请求线程中提出了一些有效的抱怨,在社区评论中得到了加强.Razvan和主要作者当时未回答这些抱怨.主作者最终决定继续前进(我稍后标记DIP为"撤回").Andrei认为值得努力解决提议中问题.

接着,Andrei谈到了内存安全,及它在更广泛的编程社区成为主要话题.Rust在销售它上做了大量工作.马克建议现在该放弃C和C++,在新的项目中使用Rust了.D需要对此给出答案.在解决安全问题前,D的GC,有两个缺点,没有优点.
当今时代,必须实现100%的内存安全.Walter同意,并说必须达到该目标.

拉兹万提出了沃尔特的默认安全DIP.现在该重新审视DIP,修改它使外(C)函数总是默认为@系统.注意到有个DIP,这里.我读了沃尔特说得够清楚了的外(C/C++)函数节.作者一直未回复,沃尔特建议,应该试着找人来接管它.

现在,我放弃了最终审查回合,所以DIP在大修前,在推送给Walter和Atila前只经历一轮审查.

沃尔特

Walter从他最近的一个八哥搜索开始.他正在实现向量的SIMD比较操作符,并发现没有注册.最终设法追踪到几个月前的忽略了的因为八哥而禁止XMM分配寄存器的一个PR.他可修复提示该PR的八哥,并重新启用XMM寄存器分配.

因为被禁止了,他一直在研究SIMD比较操作符.在D中第一次实现向量操作时,对它们有个误解.最近,他再次研究APL语言时,现在一切都理解了.

然后他发现SIMD,类似硬件上的它误解了的APL语言.所以他实现了缺失的比较操作符.他说Iain有些保留意见,但是Walter认为这是最好方法.

这是GCC实现向量指令,GPU需要向量指令.在D中,他很高兴的使SIMD操作成为一流的特性.他仍然需要决定如何处理数组操作.它们应按相同方式操作,但是他打算稍后再讨论.

Martin说,在几个版本前,他就已在LDC中实现了向量操作.他谈到了一些实现细节.在大约一周前与Iain了一次谈话,Iain提出了一些关于模板的担忧,Martin同意.
随后,讨论了实现向量操作的不同方法:硬件期望什么,什么对用户最有利,它如何影响通用代码,GPU期望什么,自动向量化,掩码与标量布尔值与位向量等.

Walter接着,是修复Timon发现的DIP1000问题.他发布了几个PR,所以他在加强DIP1000方面取得了稳步进展.提出尽管很简单,DIP1000很难让用户理解.沃尔特认为,这是因为D的语法糖会模糊实际工作.

另一方面,Walter听说许多Rust不了解借位检查器工作原理;他们只是不断调整代码直到它编译.DIP1000类似:它不会增加代码中语义,它只是减少它们.所以试属性直到它工作也算部分合理.
不管怎样,编译器非常擅长推导属性.扩展编译器用来自动推导的函数种类,可大大减少使用函数属性的必要.在这方面状态良好.可继续找到,人们给他的表明DIP1000不行示例的解决办法.

Dennis指出,目前"试属性直到成功"方法的一个问题是,有时,仅当有八哥时,编译器才会成功,而当修复八哥时,在Buildkite的随机项目中失败.沃尔特说这是个很好的观点.
除了说需要优先修复DIP1000八哥之外,他没有借口.几周前,他已检查了八哥列表,检查了他发现的所有高亮的DIP1000八哥.大多数重要的问题已有了PR,他还提交了更多的PR.从那以后可能会报道一些新问题,但他和丹尼斯在使DIP1000成型方面取得了一些很大进展.他对花了这么长时间才达到100%感到恼火,但对它的发展方向感到高兴.

亚当对ProtoObject的抱怨,在这里开始.
我建议的是迁移现有对象以匹配期望功能.
人们最大的抱怨是,在现有语言中,总是存在监听器字段.不必大改,可推导出这一点;在类定义所在的同一个模块中,出现'synchronized(this)'可推导出它的必要性,并添加它到类型中(当然,这也包括'synchronized'类和方法),但在其他模块中,因为可单独编译它们,就不能这么肯定了.

这会打破使用同步(随机对象)(包括我),但迁移是很简单的(类型),且保持与旧编译器兼容性,所以这是最小痛苦.
或删除它,并要求使用显式互斥字段,这也有很多优点,但更具侵入性,表明完全删除同步类和方法语言特性.
dip中其他抱怨包括已修复了的opEquals(可删除,但也可无害保留),删除工厂,opcmp(如果调用它,它会抛!可简单地删除它),及最近随机破坏性更改(及会破坏代码的坏更改)的opHash,所以,其他一切都已在Object自身中解决了.