void handling in expression lambdas and lambda conversion

[Peter Levart]

On Wednesday 13 January 2010 23:18:13 Neal Gafter wrote:
> > It is clear, but the intention is different. The intention of:
> > #void(int) lambda = #(int b) { method(a, b); }
> > is to construct a nothing-returning lambda regardless of what the method
> > returns. The intention of:
> > #void(int) lambda = #(int b) method(a, b);
> > is to construct a lambda that has the same or at least assignment
> > compatible return type as the method.
> 
> 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.

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. I just think it is a nice fit, provided it does not cause any trouble.

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?

Regards, Peter