Primitive values and void

[Nir Lisker]

>
> 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.


This made me think of cases of the so-called "ternary expression" that
doesn't work with `void`:

boolean b = i == 3 ? boolean1() : boolean2();
??? = i ==3 ? void1() : void2();

where the methods return `boolean` and `void`. While I understand that the
point is assignment, and that assigning to `void` is meaningless, we can
still assign to technically `Void`. Probably, the only reason to deal with
this is if we accept the "ternary expression" as a full shortcut to
if-else, and not only to if-else assignments. This is probably too far off
the mark though.

On Tue, Feb 16, 2021 at 11:15 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> 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
>
>
>