Remove Void

Pull request

Table of contents

Problem

The Void type as currently specified is redundant with (), the type of a tuple with no elements.

Background

Issue 443 contains further discussion of the problem, and possible solutions. The consensus of the Carbon leads was that Void should be removed.

Proposal

Remove Void from the Carbon design.

Rationale based on Carbon’s goals

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,

Alternatives considered

  • Define Void as an alias for (). This is workable, but forces users to understand both spellings, and make a style choice between them.
  • Define Void as a distinct type from () with the same semantics. This forces users to know “which kind of nothing” to use in any given context
  • Define Void as a distinct type from (), with more C++-like semantics. This would reproduce the problems of C++’s void, for no clear benefit.
  • Eliminate (). This would needlessly complicate programming with tuples, especially in variadic settings.

See issue 443 for details.