d的di问题

原文
总之,是的,扩展为推导普通函数,而不仅是模板属性是要做的.
目前没有的原因,是它使.di声明与.d定义不兼容.

虚函数表明覆盖,表明它们的属性是通过协变和逆变规则继承的,这与属性推导不兼容.
:绑定到"回调"的参数不能推导其参数类型.
我发布的版本可以.
.di在影响某种策略前需要更好:
1.它需要指定编码风格来改进输出,比如在函数自身中编写导入,尽管应只暴露真正需要的.如类,接口,类型.除非用户不公开导入常量或函数,否则除非它在模板中,不必输出它们.
2.可用来缓存CTFE.据我所知,现在还不行.但它会为D社区带来巨大收益,并使其更具吸引力.
3.在生成时,可传递推导给.di文件,表明:

int add(int a, int b){return a+b;}

可很容易如下输出到.di:

@safe pure nothrow @nogc int add(int a, int b);

这甚至可节省使用.di时间,因为它节省了在库代码中推导类型的工作.
我会说缺乏支持.di的工具.dub不能很好地与.di文件整合,这也是我不使用它的原因之一.

另外,正如亚当多次说过,生成.di代现在还很原始,所以,有很多手工工作,解决这些项目可得到改进.
另外,可创建专门只实例化一次模板的属性,比如'@noexport',表明,在.di输出中,不需要保留模板.这对不导出只用来内联的ctfe代码很有用.

Dub并不抽象.di生成器.但是它很容易传入标志让它干活.这不是限制因素.
事实是,.di生成器不生成可用的D代码,也不按我可用方式生成.

目前状态,它是无用的,需要解决dmd的DLL正确工作问题.
静态库和共享库的唯一区别是导出,上次试时这不是个问题.