[External] : Re: Primitive values and void

[Brian Goetz]

On 2/16/2021 9:08 PM, Nir Lisker wrote:
>
>     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();

Indeed, this is the sort of accidental complexity that would have to 
either deal with `void` as a new type, or be adjusted to explicitly 
disallow void expressions in either of the arms.  None of this is likely 
to be impossible, just tedious.

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

I think the logical way to look at this is to let the construct define 
how it handles void or not, and then treat Void as the box for void, 
just as we treat Integer as the box for int.  (Boxing conversions will 
get adjusted as part of Valhalla, but the concept will still be around.)