void handling in expression lambdas and lambda conversion

[Neal Gafter]

On Thu, Jan 14, 2010 at 12:44 AM, Peter Levart <peter.levart at marand.si> wrote:
>> In any particular context in the source, the method's return type is
>> either void or not.  So I don't see any hardship in treating them
>> differently.
>
> True, but source can be changed. Changing method's return type does not have effect on this statement:
>
>  #void(int) lambda = #(int b) { method(a, b); }
>
> But it has effect on this:
>
>  #void(int) lambda = #(int b) method(a, b);
>
> Maybe I want the compiler to trap such an "incompatible" change.

Maybe, but I don't think that has much to do with closures: you might
want to trap such changes in code that has no closures too.

> Why would I want that? I don't know for a particular usecase, but designing language with usecases is not the right approach as you pointed out.

Right, which is why a solution to this desire that isn't specific to
closures would be more appropriate than one that only works in the
context of an expression lambda.

> Then I have another idea which I don't know if it is good or bad yet.
>
> If the terminating expression in CfJ 0.6b block expression was also relaxed to allow "void" expressions, so that the following would be legal:
>
>  (S; voidMethod())
>
> And we defined another meaning for keyword "void" to represent not only void type but also a "void" expression, then expression lambdas with void return type could look a little less awkward:
>
>  #void() lambda = #() (statements; void);
>
> instead of:
>
>  #void() lambda = #() (statements; (Void)null);
>
>
> What do you think?

I think that I don't know what problem you're solving.  Do you believe
that this awkwardness will interfere with real software engineering?
In most cases, the programmer could just use a statement lambda.
Alternately, if the context benefits from transparency, she could
write "null" (it is a subtype of java.lang.Void) as the final
expression to be more concise.

Cheers,
Neal