原文
沃尔特和我昨天就标准库3
进行了富有成效
的对话,认为分享一些关于讨论的笔记
是合适的.
谈话开始时,我摸索着了解版本
如何影响
标准库.讨论围绕两个主题
展开.
首先是如何构建标准库3
的包结构
.Walter
提议使用std2.
作为根名字空间
.主要原因
是,想避免从std.
导入可能触发自动解码
的东西.
我指出了该设计的两个主要缺陷
.
首先,很容易在std2
中意外键入std.模块
.且发现,无论使用什么根名,这都是一个问题
,适当
答案是指定一个Phobos
相关的DStyle
规则,即只有std.
中的模块
才能导入std.
模块.
其次,该设计表明std2
中的"2"
.是一个版本说明符,它将随着每个Phobos
版本的发布而递增.这不是本意,一致认为这会令人困惑.
我建议使用sys.
作为标准库3
的根名
,沃尔特认为这是可接受的.简要
地讨论了把标准库
分成多个根源
的问题,但没有明确达成
一致.
另一个主要讨论的话题是我所说的"默认残废
"版本设计,其中如果未指定版本
,最旧
版本(是上个
预版本)是默认
版本.
从终端用户
角度来看,这有点难,但是,在工程
中,总是想默认或简单"正确"
,然后必要
时提供后门
.
因此,编译器
应默认使用最新版本
,然后通过开关
设置模块版本
或导入路径缺少
的功能版本.这解决了废弃包
可访问问题,而不会向新用户
提供越来越旧的编译器版本
.
想尽量向前迈进
,并展示不断变旧的上个预版本
.
然后,他继续讨论Walter
设想的版本
如何实际工作.因为没有人看过Atila
正在编写的文档,Walter
分享了他对它应如何工作
的看法.
Walter
想看到一个指定实验功能
的版本属性,然后每年
有个包含上一年
所有推广功能
的"汇总"版本的"混合"
方法.
因此,如果DIP1000
升级到2025
版,则,无需专门启动它,DIP1000
默认在该版本和所有后续
版本中活动
.
确实可能导致另一个"函数属性汤
"问题,但总之,我完全同意版本
应该用该模型
,C#
和C++
都这样,所以对来自这些语言
的用户
来说,概念
上会很舒服.
此后,讨论了如何分发
标准库.主要集中
在发布节奏上.我主张关联标准库
版本与版本发布时间表
.这是明智的,你更容易推导正在使用的编译器/库
配对.
沃尔特
对此表示满意,但他不想用"版本"
语言来描述标准库的发布.这是对的,因为Phobos
并没有真正的版本,但在SemVer
之后,它每年都会发布主要版本
.
即新功能
每年发布
一次,且在年度版汇总
间的DMD
的快速节奏时间表上发布错误修复
.
最后,简要
谈到了想在标准库3
中看到的主要变化
,这些是迄今为止为标准库3
承诺的主要变化
:
1,删除自动解码
.
2,从实验
中推广分配器
.
3,重新设计区间接口
(见此处的JMD
线程)这里.
4,修复std.traits
.
以上列表
并非全部,可接受进一步的建议.就我而言,我很想看到Cryptography
和StreamAPI
进入Phobos
,但我确信社区想要添加的内容列表
会有很多
,因此这些最终可能会降低优先级.
如果可能,我想安排计划与参与该指定更改的人的会议,这些更改流式传输到YouTube
,以便社区可通过Discord
参与.
如果想参与标准库3
的设计讨论,我目前正在GitHub
上管理一个仓库,其中包含来未解决/未设计
主题的GH
讨论,及来编辑实际设计文档的PR
.链接在此:这里