The philosophy of Nothing
Neal Gafter
neal at gafter.com
Mon Nov 30 09:05:01 PST 2009
On Mon, Nov 30, 2009 at 8:57 AM, Paul Benedict <pbenedict at apache.org> wrote:
> I am moving this discussion to closures-dev because that's where it
> should have been from the beginning. The original thread is here:
> http://mail.openjdk.java.net/pipermail/coin-dev/2009-November/002573.html
>
> Neal,
>
> Thanks for all your explanations thus far. What I am concerned about
> is the simplicity of the language. I fear having three very similar
> Java type for nothing is going to make the language confusing:
> * java.lang.Void
> * java.lang.Nothing
> * null type
>
> When I sit down and think about the need for java.lang.Nothing, I
> can't answer why java.lang.Void isn't considered. That effectively is
> nothing (a void). Couldn't that existing type fit the bill?
>
> Given this example:
> #() { throws AssertionError(); }
>
> Couldn't the compiler infer java.lang.Void and prevent assignment?
>
The requirement is to *allow* assignment to a variable of type #int(), not
prevent it. The issue occurs no so much in the lambda conversion (where
Nothing is not required for this behavior), but in the function subtype
relationship.
Void is a *unit* type, having a single valid value. As such, it is legal
for void to occur in the flow of a program (and indeed it does occur
everywhere you call a void method). Nothing on the other hand has
*no*valid values. As such, reachable statement analysis can correctly
infer
that calling a method whose result is Nothing cannot complete normally.
Cheers,
Neal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091130/4ae0102d/attachment.html
More information about the closures-dev
mailing list