d推导属性的想法-CFANZ编程社区

原文许多人要求更多自动推导属性.

推导属性

今天D为auto返回及模板推导属性:

auto foo() { }

void bar() {}

pragma(msg, typeof(foo)); // pure nothrow @nogc @safe void()
pragma(msg, typeof(bar)); // void()

注意,不用写,foo自动得到pure nothrow @nogc @safe,这就是推导属性.
rikki cattermole提议扩展它,来方便关注属性的用户.我喜欢,但要注意:

运行时调度
函数文档
兼容合同
依参属性
ABI和.di文件兼容性

运行时调度

先要知道这些是静态属性,除非强制,与运行时调度不一致.

interface Foo {
    void func();
}

class Bar : Foo {
    void func() {}
}

示例中,显然无法推导Foo.func,因为没有可分析主体.可继承它并干活;接口不做保证(当然,除非接口明确指定了一些属性,迫使它的所有实现至少也如此严格).
但是Bar.func确实有一个主体.可推导出来吗?好吧,如果它是final,我会说是的:在子类实现上使用比父接口要求更严格的属性.所以与父接口的关系不是障碍;可按需严格的推导,并且仍可实现.

但是,由于Bar.func不是final,因此调用它时,并不知道实际调用的函数体.考虑:

class Baz : Bar {
    override void func() { some_global ~= x; }
}

void main() {
    Bar b = new Baz();
    b.func();
}

此时,即使是选择调用的Bar.func接口可能已经可使用它,主函数也不能是@nogc或pure.因为override导致运行时替换函数体.

教训是:可推导终(final)方法属性,但不能推导虚方法,因为运行时调度允许实现的正式接口替换主体.必须用显式属性限制子类,否则会破坏替换.

除非标记Baz.func为final并确保通过该接口调用它,否则推导失败会传播到main:

class Baz : Bar {
    final override void func() { some_global ~= x; }
}

void main() @safe {
    //这很好,仍可在`Baz`上推导出`@safe`,因为它是`final`,因此知道,实际使用的函数体.
    Baz b = new Baz();
    b.func();
}

函数文档

自动生成文档倾向于查看静态注解,但了解推导出的内容可能很有用.docgen希望编译器告诉docgen推导内容,但是docgen应该指出它是推导出来的.因为兼容性合同,这很重要.

兼容性合同

如果库在未来版本中推导出的属性变化了,这是重大更改吗?好吧,(就像定义重大更改一样),我的回答是"得根据你的承诺".文档定义了这些承诺,因此文档要指出静态保证和推导间的区别.

如果我写:

Color parseColor(string name) @safe @nogc { ... }

则我保证它是@safe和@nogc.如,如果要发布有分配的新版本,则是重大变化.
但是,同时,很可能推导它为pure,然后就可在纯函数中使用它.它会编译,但由于我列举pure,我不保证未来保持纯.
当然,很有可能!我可能在未来版本中添加pure来扩展保证.但是,如果将来更改为,如,从全局变量中检查用户本地,则推导不再有pure.而且由于我没有列举纯,我可叫它新功能(次要版本加1),而不是破坏性更改(主要版本加1).

这样就很好.

依参属性

因为实现而改变的推导属性是一回事,但如果它因传递不同参数而改变呢?
这在今天适合模板,但代价是另一个实例化:

void forward(Dg)(Dg dg) {
    dg();
}

void main() {
    void delegate() notSafe;
    void delegate() @safe yesSafe;

    //调用`forward`时,自动用参数类型实例化它.
    //所以调用`forward(notSafe);`它会这样:
    pragma(msg, typeof(forward!(typeof(notSafe))));
    //注意用`notSafe`创建时是,`system void(void delegate()dg)`
    //而调用`forward(yesSafe);`它这样:
    pragma(msg, typeof(forward!(typeof(yesSafe))));
    //但当用`yesSafe`创建时,它是`@safe void(void delegate()@safe dg)`
    //注意一个是`@system`,另一个是`@safe`.
    //它从参数中推导出不同的类型.
    //但请注意它是不同的类型和不同的地址:
    assert(&forward!(typeof(notSafe)) != &forward!(typeof(yesSafe)));
    //因为它们是不同的实例化!
}

模板干的是把给定参数粘贴到新函数体(a)中,然后通过推导属性系统传递a.
常见模式是使用带注解的单元测试来说明,它有时可能有该属性,测试提供了一例,这样编译器在编译测试时检查它.

但是,如果推导非模板函数体,则只有一个主体,因此要推导参数,必须使该部分成为单个类型,而不是依赖传入的多个类型.

有一个依参属性dip,该概念简称为inout属性,该想法使函数的属性依赖于参数属性.使函数其余部分比属性要求更严格.但推迟最终结果到传递内容.只需要一个函数体就可完成,不必一个函数,多个副本.

ABI和.di文件兼容性

d作者担心,属性成为混杂名的一部分,如果实现调整更改了推导属性,也会更改链接器看到名字.如果绑定不匹配,会导致"未定义引用"错误.

它放在最后,因为这是我最不担心的;沃尔特担心它.更改代码可能会破坏接口,并不奇怪,但它与更改函数体,并改名和改原型或改链接没啥区别.
可这样缓解:1)D中单独绑定相对较少,最好简单使用源码,及2)可用dmd-H自动生成它们.现在,dmd-H很糟糕(我想修复它,编译器应该可使它更好工作,另外生成.di或可能包含推导值的dmdjson输出可能是docgen的良好数据源),有时它确实有效.