Updated State of the Lambda

[Brian Goetz]

Yes, this is covered.  The formal model handles this case in the rule 
T-ClassFromDefault (Figure 6), through the precondition 
mtype(C)=mtype(J); this means that it is a type error if a class tries 
to inherit a default where the classes' notion of the return type 
differs from the implementation's return type.

While technically one could read this and not require a compilation 
error at the point where an interface covariantly overrides a default 
method without either providing a new default clause (concrete or 
default none), it would be silly to push the error to the point where 
that interface is inherited by a class.  So the error happens at the 
point at which the pollution is introduced.



On 12/12/2011 2:11 PM, Gernot Neppert wrote:
> Am 12.12.2011 12:46, schrieb Maurizio Cimadamore:
>> concrete methods, but applied to extension methods. We feel like we need
>> an explicit re-abstraction mechanism, as it is quite common in Java code
>> to repeat an interface method declaration is a sub-interface just for
>> documentation purposes. If the redeclaration was interpreted by the
>> compiler as a re-abstraction we would be introducing subtle semantics
>> change associated with such re-declaration of interface methods and the
>> only way out for the developer would have been to re-specify the default
>> implementation for the extension method (which would be the most common
>> use case, as opposed to re-abstraction, which is quite rare).
>>
>> Maurizio
>
> Another purpose of re-declaring interface methods can be to provide  a
> more specific return type (a.k.a "covariant return type").
> If, as the current proposal seems to suggest, a mere re-declaration does
> not re-abstract a method, how will that fit in with covariant return types?
>
>