Updated State of the Lambda

[Dan Smith]

On Dec 12, 2011, at 11:11 AM, 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?

A declaration with a more specific return type (or a more restrictive 'throws' clause) can't be considered a "redeclaration" -- there's no guarantee that the inherited default is compatible with the new return type.  "State of the Lambda" is pretty informal about this, but "redeclaration" is strictly limited to cases in which no new information is provided by the declaration.

In the "default method overridden without a default" case to which this scenario belongs, it seems like we have two choices: either it's implicitly "default none," or an error occurs and an explicit default is required.  I think the current thinking is to consider it an error, but that's something that hasn't been very thoroughly explored yet.

—Dan