Primitive values and void

[Brian Goetz]

It's an open question, but one we want to address.  Adjusting the 
language to understand that `void` and `Void` are related is not hard, 
allowing us to ignore the need to return a value.

Turning `void` into a proper (unit) type is harder, but ultimately 
valuable; if you look at the explosion of functional interfaces we added 
in 8, one contributor was all the primitive specializations 
(IntPredicate could be Predicate<int> which in turn could be 
Function<int,boolean>), but another was the fact that `void` is not a 
type (Consumer<T> could be Function<T, void>).  Valhalla will surely 
collapse the first (hurrah), but it would be a shame not to collapse the 
second as well.

There's a certain amount of accidental complexity that will have to be 
compounded to get there; for example, there are "statement lambdas" and 
"expression lambdas" but if void is a type, then a statement lambda 
could also be an expression lambda returning void.  I doubt any of these 
are blockers, but there's a certain amount of un-fun grinding here to 
clear out the underbrush.



On 2/16/2021 3:48 PM, Nir Lisker wrote:
> Hi,
>
> After reading the JEPs about primitive objects (.ref and .val) and the
> conversion of primitives, I was wondering what happens with void and Void.
> They are not interchangeable like primitives - a method returning void must
> have 'return;` while a method returning Void must 'return null;' - but they
> are the same semantically. Since Void mainly (only?) exists for generic
> types purposes, will void be valid as a generic type and make Void more or
> less useless? Will they have reference-value conversions like primitives,
> if that makes sense?
>
> - Nir