The Void type as
currently specified
is redundant with (), the type of a tuple with no elements.
Issue 443 contains
further discussion of the problem, and possible solutions. The consensus of the
Carbon leads was that Void should be removed.
Remove Void from the Carbon design.
Eliminating Void will make Carbon code
easier to read, understand, and write.
The main advantage of Void is that it is recognizable and familiar to C++
programmers. However, we haven't yet found any use cases where using Void
results in clearer code, even to programmers transitioning from C++. In
particular, omitting a function's return type is more concise and at least as
clear as explicitly specifying -> Void. In most other use cases, the
appearance of familiarity is more likely to mislead than to clarify: most other
use cases for C++ void, such as using void* to mean "pointer to anything",
will not work with Carbon's Void, and most other use cases for Carbon's
Void, such as using it as the type of a variable, would not work with C++'s
void,
- Define
Voidas an alias for(). This is workable, but forces users to understand both spellings, and make a style choice between them. - Define
Voidas a distinct type from()with the same semantics. This forces users to know "which kind of nothing" to use in any given context - Define
Voidas a distinct type from(), with more C++-like semantics. This would reproduce the problems of C++'svoid, for no clear benefit. - Eliminate
(). This would needlessly complicate programming with tuples, especially in variadic settings.
See issue 443 for details.