Attribute inference for auto functions?

[Timon Gehr]

On 04/18/2013 01:46 AM, Walter Bright wrote:
> On 4/17/2013 3:20 PM, Timon Gehr wrote:
>>> "This is the same issue as defining a function with 'auto' in one place
>>> and referring to it having a specific type/attribute in another. So I
>>> think all the same arguments and reasoning discussed above apply
>>> equally."
>>>
>>
>> Why is this a valid form of reasoning? The signature of a function
>> that has its
>> return type inferred includes the function body.
>>
>> Furthermore, it is not the same issue. It is the dual issue. The
>> distinction is
>> very relevant because pure and nothrow are designed in an asymmetric way,
>
> They are the same

No. In one case you infer guarantees only. (those restrict what can be 
done in the future without potentially breaking code, but that's it.)
In the other case you infer restrictions too, in an unsound way because 
the inference does not take into consideration the subclasses.

> - adding the attribute retains covariance.
>

I am sorry, but I do not understand your notion of covariance. 
Covariance is a precise notion from category theory. (A mapping between 
categories that conserves morphisms is called a covariant functor.)

>> given
>> inference. Attributes can force the specification in one direction
>> only (provide
>> more guarantees to callers), but not in the other one (require less from
>> subclasses).
>
> Pure and nothrow provide more guarantees, hence covariance.
>
>> The concerns the latter can certainly not be dismissed by using the same
>> arguments and reasoning as for the former without any further
>> examination.
>
> They're both the same issue of covariance.
>

class C{
     final foo(){ ... } // <- this signature is foo's signature only
     auto  bar(){ ... } // <- this signature has to fit all overrides
}

In the first case, inference is mostly fine because you cannot unduly 
restrict someone: The signature will actually match foo's implementation.

In the second case you cannot infer the attributes because you do not 
know all subclasses. The signature will potentially not match all overrides.

Case in point, I just noticed the following regression on git head:

import std.stdio;

class C(T){
     T foo(){ return 2; }
}

class D : C!int{
     override int foo(){ writeln(super.foo()); return 3; } // error
}


Inference shouldn't be done for virtual functions.

http://d.puremagic.com/issues/show_bug.cgi?id=9952