2308d8月会议

原文

罗伯特

罗伯特说他很高兴.Dennis问编译器是否足够快.
他只是想在编译器中看到LSP支持,并利用所有好东西.
Walter指出,他一直致力于提高编译速度.他发现编译器是带异常编译的,所以他一直在努力无异编译,看看这对速度有什么影响.

亚当说他的库在半秒钟内完成编译.罗伯特说这还是太慢了.他的工作项目没有在半秒钟内完成.他说他的目标是,在Ninja或他使用的构建工具/编译器上按"Enter"键后时,它应该已重启了应用.
阿蒂拉同意半秒太长了.
亚当提出了D1.他在2007年写的一款旧游戏在10毫秒内编译和链接.查看D1和D2之间的很大差异,当时的object.d大约有600行.
而现在它要大得多,因此.沃尔特说,他对object.d的状态有点不高兴.它应该是一件小东西,在某个时候变成了个垃圾场.

史蒂夫

Steve说,Dennis在初化静态关联数组的编译器部分的PR方面做得非常出色.史蒂夫认为,如果有人能按下按钮,它就准备好了.
他不想推动它,因为他不太了解编译器代码,也无法保证它的正确性.此时PR仍开放这里.

丹尼斯

丹尼斯说他一直在做AA公关.还有一些,比如查看弃用(-d/-de/-dw)和过时警告(-wo)开关的模式支持,及静态构造器的独立属性(standalone)或编译指示要做.

八月会议以来,丹尼斯已提交了@standalone属性的PR这里,但在PR讨论线程中,沃尔特认为这应该是个编译指示.

马丁

马丁说,在LDC升级至2.104前端方面进展顺利,且非常轻松.
接着,他看见一篇关于让LDC在8位AVR平台上工作的论坛帖子.他研究了该问题,发现这是个有趣的问题,即是否及如何支持指针大小小于32位的架构.
目前,前端有一个硬编码限制:size_t和ptrdiff_t是32位或64位,且不能小于它.这是个前端检查,DRuntime中的定义直接根据编译器的内部类型,因为它们使用typeof式.

他让前端接受16位和8位size_t和ptrdiff_t,但这样做会违反整数提升规则.使用较小的int时,提升规则有时工作,但是有类似切片长度或加一或减一时,这是个问题.

需要转换它.因此,或需要改变提升规则,试模仿C++的此方面,或做得更好.他说亚当在过去的讨论中提出了,可一般处理它,所以它仍是目标独立的.
Walter想知道Rust是否支持低于32位的编译,及他们为此做出了什么妥协.马丁说他不确定.他只检查了C和C++.
Robert查找了一下,发现Rust对16位MSP340有一点支持,但它是一个大星号,其他一切都是32或64位.

马丁不确定是否值得研究这些架构,因为他不知道它们会存在多久.对低功耗,即使你提前几年玩,即使是那些非常小和节能的传感器,或其他什么,它也将是32位.
但是他无法展望未来,所以他没有真正的想法.

Walter说,当他设计D时,16位架构已死了,每个人都会使用嵌入式32位处理器.但这是个巨大的简化.在C中有很多麻烦,因为不能预测整数大小.
只是无休止的问题和痛苦.

沃尔特

沃尔特说,他一直在修改编译器前端,以便让DMD更适合作为守护程序.
为此做了不少改变.一些PR仍在那里,等待拉动.想法是查看D的子系统,并删除全局状态依赖,及环境和操作系统的依赖,以便有个取需要的所有参数,执行操作,并返回数据的简单的入口函数.
然后,调用者可决定是否写入文件或如何处理错误消息,等等.
他说,这样设置时,有点令人满意.错误槽是他朝该方向的第一次尝试.词法器和解析器现在可与编译器的其余部分分离,且可重启.
表明LSP守护程序或内容都可是多线程的,因为你可用此设置同时多个编译.还有很长的路要走,但它正在继续.
他还在考虑重定义胶水代码接口,这样会让伊恩和马丁生活更轻松一些.马丁说他不太确定.当前状态下的接口绝对没问题.

Walter说他已提交了大量PR来从文档生成器中删除所有外部依赖项,且已接近完成.他已分离出宏处理器,因此它现在是独立的.这就是他一直在做的.
他接受了罗伯特的观点,并认为这很重要.Razvan没有参加会议,但Walter很好奇他的想法,因为他一直在为按库使用DMD工作.
他问罗伯特,DMD作为库和LSP服务器期望工作是否相同.

Robert说,DMD作为库是构建LSP的一个重要构建块,但是在构建接受命令,运行编译器并返回JSON信息的服务器方面,还有更多.
编译器库是其中的重要组成部分.其余的只是胶水.
然后Walter感谢Steve和Dennis致力于静态初化AA.很长一段时间,他一直认为这是不可能的.史蒂夫说服他这是可以合理完成的.

最后,Walter向Mathias提出了-preview=in的问题.他记得在一次会议上讨论过该功能应总是通过引用传递,但是查看实现时,他发现没有更改它.
它仍采取原始方法,根据情况按值或按引用传递.马蒂亚斯记得,并同意改变它,但未完成.他说马丁说他会保留LDC目前的行为.
沃尔特问马蒂亚斯是否想改变.马蒂亚斯说他会这样做,而且会以不会阻止LDC方式这样做.
沃尔特建议马丁为LDC做出改变,因为改变是有充分理由的.马丁说,这里存在分歧.这是他10年前想看到的功能,他很高兴Mathias实现了它.
他不会转储它,但可能会把它放在开关后面以启用或禁止它.这并不理想,但他非常喜欢该功能.

沃尔特说这是个可靠性问题.如果总是通过引用,则它是可预测行为.拥有可预测和可移植的行为非常重要.马丁提醒他,很久以前就讨论过该问题.

他仍强烈认为,一旦把每个这种都当作引用,或对引用工作,但不依赖标识,就没问题了.
99.99%的代码都是这样.这很好.对ldc,会良好定义.不是实现定义的,而是依赖目标.

马蒂亚斯说他同意马丁的观点.但是,只需使DMD总是通过引用传入参数就可以了.这是上次讨论时想出的最好的折衷方案.

Ali确认此功能解决了右值引用问题.如果想接受右值,只需使用in.马蒂亚斯说确实如此.
Mathias说,他已看到唯一阻止预览完成的是前端中的一个错误,它与另一个与预览无关的错误相关联.这有点难.
这与CTFE有关,但他没有时间深入研究.所以它仍被阻止了.他说这是明确的,他只是需要有人来解决问题.丹尼斯说他会调查一下.
马丁认为该问题阻止了他的一个旧公关.他不记得是哪个PR,但他确信这是同一个CTFE问题.问题是根本不会析构CTFE语句中的临时变量.
很难得到与运行时相同的析构行为.
沃尔特说,他可预见这是个麻烦.CTFE引擎一团糟.

Dennis想知道一旦开始在CTFE中运行析构器,是否会破坏代码.很多析构器只是调用释放(free).Martin指出,必须在先分配的东西上,调用free的析构器.
这在ctfe上行不通.当前默默跳过所有析构器的行为是错误的.大错特错.
史蒂夫说,如果打算在CTFE使用的析构器中释放,已有if(__ctfe)分支来解决malloc.析构器中因此也要有它.不稀奇.