Primitive values and void
brian.goetz at oracle.com
Tue Feb 16 21:15:40 UTC 2021
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:
> 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
More information about the valhalla-dev