The feasibility of unifying the void as type

[Brian Goetz]

You are correct that it seems possible, and that this idea has many 
attractive aspects.  For example, we may be able to unify everything 
under one `Function` type:

     interface IntFunction<T> extends Function<int, T> { }
     interface ToIntFunction<T> extends Function<T, int> { }
     interface Consumer<T> extends Function<T, void> { }
     interface Runnable extends Function<void, void> { }

For another, we may be able to unify switch expressions and switch 
statements, where a switch statement is a void switch expression.

So the opportunities are very attractive; the devil is in the details.  
There is much JLS to be combed through, to evaluate whether we can align 
these concepts.  (For example, we currently make a distinction between 
void-compatible and value-compatible lambdas in overload selection; if 
these merge, would this result in incompatible changes to overload 
selection decisions?)

So this has been "on the list to investigate" for a long time, and we're 
hopefully soon coming to the point where we can do so.

On 5/18/2021 6:22 AM, Glavo wrote:
> I know that up to now, the void is not a type in JLS, but it also has many
> similar features.
>
> In Valhalla, it seems that the void can be implemented as a special
> primitive class, so that it will be more useful in generic code (e.g.
> `Task<void>`, `Function<T, void>`), and it is easier to be optimized by the
> compiler than the current `java.lang.Void`.
>
> I want to know the feasibility of this idea and the problems it may bring,
> because this proposal seems very attractive.