Preparing for the 0.2 draft

[Alex Buckley]

Alex Blewitt wrote:
> Lastly, say we allow SAM on (abstract) classes iff they have no (non- 
> final) fields. We then end up with an evolution problem in that L can  
> extend A and be compiled, but then a field is added to A giving A'. So  
> it won't compile any more but now we have a problem with the compiled  
> L, which may be in a different file. The same holds for removing the  
> (implicit) default constructor.

Sorry, terseness factor too high. I think L is a lambda expression and A 
is an abstract class and you mean to apply a lambda conversion from 
typeof(L) to A?

Binary incompatibility is always possible with separate compilation. If 
lambda conversion could only target interfaces, not abstract classes, 
then removing a method from a SAM interface will cause problems for 
lambdas that were converted to the earlier definition of the interface.

Source incompatibility is more interesting: adding a method to a SAM 
interface (binary *compatible* but source *incompatible*) will cause 
problems for lambdas that were converted to the earlier definition of 
the interface.

(Of course, a good module system will provide a version scheme to 
document binary/source incompatible evolution, and a static mechanism to 
identify client modules affected by such evolution ;-)

Alex