D 1.0发布了!

我愤慨的是，D不支持string interploation("my name is $name")和here-doc。
对D坚持C/c++/java的switch的fall-through语义也表示不满。


赞赏D的：
built-in string （c++ std::string没得比）
built-in hash
scope关键字 (就是我以前设想的auto关键字，而且更强)
gc
支持手工内存管理
漂亮得多简单得多的template-programming
type inference
typeof
对拷贝的认识（除了bit-copy，手工的copy-ctor基本没用）
放弃和C++兼容这个历史包袱。让c++代码就地臭掉。保证了D的纯洁性，简单性，使得编译器以及相关工具相比于c++容易几个数量级。

一如既往，我们两个共同点不多 …………

我比较喜欢的 D 语言特征：



感觉比较复杂犹豫的：



看着不太顺眼的：



嗯，总的来说，感觉 D 这门语言里面缺乏创造力，只是根据 C++ 社区里面抱怨的声音头痛医头脚痛医脚，给出的解决方案老套而且效果不理想。

所以它才支持了额外的手工分配内存阿。而且据walter说，真正的实时系统，都不用动态分配内存的，不管是gc还是malloc都不成。



我不担心。反而很鼓舞。这东西的思想跟我当年鼓捣cg颇有点一致。Walter说了，除了操作内存，基本上copy-ctor没用。哈哈，那啥所见略同阿。
:D



hash很常用阿。既然数组，字符串都有内置的方便语法，为什么hash就不可以？D看起来明显是以实用为目标，不是死抱着“用库实现一切”的教条。


看一些关于D的讨论，递归调用的能力似乎曾经被人提议过，就是把scope关键字用在类成员变量上。不知道Walter有什么考虑，为什么没有加。也许是认为用处不大。这个还要真正用D写些东西才能发现是否重要。
另外一点，因为废除了copy-ctor，似乎对象所有权就不能象c++里面那样由类代码静态地写死了，而是更适合由用户根据当前上下文灵活决定。面向接口+依赖注射的设计风格也和c++的那种某个对象被一个父对象独家拥有的设计方法格格不入——一个对象被几个对象引用是注射代码决定的。



被delete的变量会被置成null。对gc的实现干扰大么？c++程序员不是一直希望gc是可选的么？这个手工delete不是正好满足要求？

是spec规定这样做么？其实D才1.0，不排除以后更智能的编译器搞全局优化吧？


1.0版。


比如说，什么c++能做的类型抽象D不能做呢？type list？似乎用tuple实现起来很简单阿。
至于static_if，不错。要是能使用if然后让编译器自动分析这个if是不是static的，会更好。不过，编译器实现的难度会加大把？至少，static_if比c++里面的对应东西好太多了，就算不完美，也不错了。


d支持mixin吧？

老规矩，我先放过自己也感觉比较复杂，并不是特别确定的东西，把火力集中在我明确觉得不爽的东西上面。



因为 hash 不像数组和字符串那么单纯，这东西有一些内部实现上的考量。散列区的大小，冲突如何解决，诸如此类。在性能比较重要的情况下，hash 一般还是要自己来设计和调整的。所以我乐于见到内置的数组和字符串，但是对于内置的 hash ，就会觉得比较鸡肋，有点多此一举。



你就爱扯这个设计风格，其实这里的问题和对象所有权根本就不相干。递归调用是个方便的工具，当我对一个对象执行 close 动作的时候，释放所有它所引用的资源是很正常的举动，支持递归调用在这里可以减轻程序员的簿记负担。



被 delete 的那个变量几乎不可能是问题，问题在于如果有多个变量指向同一个对象，一个 delete 了，其他的怎么办？用其他变量访问那个对象会是什么结果？难道 D 的运行时还能把所有指向那个对象的变量都置成 null？

另一方面，手工 delete 对 gc 的干扰是很明显的。D 里面手工 delete 对象之后，那块内存可以在后续的 new 里面直接使用而不需要先经过一次 gc 么？如果不行，那这个手工 delete 实际上毫无意义，如果行，那么这里就需要内存分配器与之配合，而且此时将很难采用基于节点复制算法或是支持缩并的 gc 机制。虽然这并不意味着我们无法找到较好的解决方案，但这个手工 delete 对 gc 的实现是一种干扰则是确定无疑的。

要让 gc 是可选的，正确的做法是提供一个传统的、手工分配释放内存的堆，而不是让 gc 堆支持 delete。




1.0 的盾牌都出现了呀 …… 好吧，这个就放过好了，毕竟只是一个优化的问题。



这个再用 1.0 盾牌就不像话了。D 既然把目标放在系统编程领域，又废掉了和 C\C++ 的源代码兼容，那解决这个问题绝对应该放在相当高的优先级上。话说 D 虽然刚刚 1.0，可是 0.9x 了不是一年两年了吧？



问题在于 D 引了一大堆 static_if 之类的东西进来，对 meta-programming 里面最有价值的部分，也就是对类型的计算，却没看出来有什么帮助，我还是不能用干净清楚的语法来书写一个函数，以一个类型为参数，返回另外一个类型。最基本的例子，我有一个函数模板，希望当用来实例化的类型是 int 的时候，调用一个函数，对于其他类型，调用另一个函数。那么在 D 语言里面，我可以这样写么：

static if (T==int)
    foo();
static else
    bar();

还是和在 C++ 里面一样，我需要写一个类模板再加上几个特化版本做 traits 才能实现这个东西？

除此之外还有一个问题，是关于 Expression Template 的。貌似 D 语言里面 operator overload 都是做为类的成员实现的，同时貌似 D 语言里面不支持成员函数模板，那么 C++ 里面玩儿 ET 最基本的东西，下面这样的 operator overload ，如何实现？

template<typename L, typename R>
expr<L,R> operator+(const L& lhs, const R& rhs)
{
   ... ...
   ... ... 
}

D 的 mixin 限制很大吧？我怎么记得要用专门的语法来声明哪些东西是可以被 mixin 的？

字符串好像也不单纯来着。：-）
万一内置的hash不合适，你自己写一个合适的不就完了？问题是可能90%的情况内置的hash够用了。





风格当然有关系了。在java里面，用依赖注入的风格写程序也这么长时间了，怎么我就从来没发现有这个传说中的“簿记”负担的？



嗯。不清楚。我想可能是如果用new/delete就通盘都用new/delete吧？毕竟对这种特殊需要自己控制内存的应用，gc根本就不受欢迎的。



是慢了一点。我等这个1.0也等了很心焦了。话说当年B教主写c++，1.0是花多长时间推出的妮？



对int的特化我怎么不觉得static_if有什么好？直接写两个版本的函数不是很好？当然，似乎你这个static_if版本也是合法的。

你说D不支持成员魔板？确有此事么？那我也要和你一起跳脚大骂了。



多继承本来就姥姥不疼舅舅不爱，替代品有点限制你就将就吧。

90%？你还真乐观啊。而且问题是只有剩下的那些情况，hash 才有真的意义，否则的话既然性能不是那么重要，我们要的只不过是一个可以用非整形值索引的集合而已，放一个平衡二叉树都要好得多了，至少不用提供 hash 函数。为了这种需求去改核心语言，说句鸡肋，不过分吧？

PS: 你为啥说字符串也不单纯？有 GC 支持的情况下，选择 immutable 的字符串基本上不用考虑吧？




容我不厚道地问一句，你写的这些程序里面，有多少东西是用完之后必须尽快关闭的？
不论对象所有权，不论对象生存期，不论某个对象使用的资源怎么传进来的，如果我希望这个对象 close 的时候对所有它引用的资源执行 close ，那么这个簿记负担就冒出来了。




那它到底是怎么做的？通盘都用 new/delete 是说这个程序里面 GC 就废了吗？不可能吧？



别扯开话题，D 既然废了和 C/C++ 的源码兼容，那这个问题就应该要尽快而且妥善的解决。而且这不是什么很困难的火箭科技吧？貌似你这厮当年在 abp 上不是也鼓吹自己找到了一个更好的方案么？



直接写两个版本的函数不就退回 C++ 的解法了？我对 C++ 的 TMP 最不满的就是这个类型计算了，每次想要表达“根据输入的若干类型，输出某个特定类型”这种概念，都要重载特化折腾半天，可读性 N 差。

另，俺去看了 D 网站上的介绍，一个类不能拥有函数模板做为成员，和我一起跳脚骂吧。



偏偏我这个远方堂叔挺喜欢多继承带来的语言表达能力，凭啥就让我用限制多多的替代品？

社会不是公平的。总有少数人的利益受到侵害。我很同情你。

提供点信息，供你们跳脚之用：

1、成员函数模板是支持的，从某个版本开始。。。时间是记不得了，不过至少已经是2个月以前了吧，大家一起跳脚骂吧。。。

2、new/delete的问题，不算是语言的问题。举个例子，假设一个socket对象不能够多次close，但你有多个对象引用它，谁该来真正close？这个问题换成是delete它就成了语言的问题了？GC自己是可以处理和delete的共存问题，你自己处理不了，不是语言或GC的问题。。另外，你可以自己写new/delete方法，这样就可以和GC完全不相干，具体方法文档中都有。

3、把历史上多继承的讨论都搞到一起，肯定可以印一本大布头了，所以优劣就不用再争了。不支持多继承的语言可以简单地使用聚合来代替，重新引出接口即可。

4、D 1.005新增了mixin表达式和import表达式，这又是个类似动态语言eval的玩意，不过是在编译期进行，要批判不妨连这个也一起。。对于这个玩意，我简单介绍一下，比如我有一个文件user.model:

model User
  has_many posts
  field name, string, null: false, limit: 255
  // ...
end

mixin ImportModel!(import("user.model"));

如果我足够厉害的话，可以把上面的user.model在编译期生成这样的代码：

class User : ActiveRecord.Base{
    public ActiveList!(Post) posts;
    private char[] string name_;
    public void name(char[] s){ name_ = s; }
    public char[] name() { return name_; }
}

然后就可以直接使用它：

mixin ImportModel!(import("user.model"));
void main(){
    // 设置数据库连接
    User u = User.find_first;
    auto users = User.find_all("status = ?", 0);
}

当然这只是我想象的，但目前的语言设施是支持这种变态操作的，只是我还没有足够的实力驾驭它。当然我也在努力学习它使用它，目前只做了个简单地词法分析器，把它分割成token。由于只能使用模板，所以要在一个受限的语言环境下完成这东西还是相当困难的。不过它作为D 1.005的最大更新，应该可以看出D语言的一些方向。

5、关于模板，不完善的部分都是暂时的，D语言在这方面投入了相当大的精力，所以目前的不足可能在后面某个版本被改掉。

觉得学要一门语言就好了。不要追求太多。

新人报道！
google告诉我这里几乎是唯一有讨论D的中文社区？