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
