Chandler CarruthandRichard Smith
94d2c1c6d4
We've talked about adding the title to the filename several times over the years and it seems really valuable. This requires us to compute a "slug" for the title spelling that can be part of the filename. Beyond that, we crossed 7000 recently, and so it seems likely that we will need to add digits sooner rather than later here, so this goes ahead and moves us to 6 digits so we don't have to adjust again for a reasonable length of time. To implement this and ensure we can sustain it going forward this adds a tool to our pre-commit that validates (and corrects if needed) the filename. In order to update everything and keep links working, there are a _lot_ of changes, but the most interesting for direct review are in `proposals/scripts`. Assisted-by: Antigravity with Gemini --------- Co-authored-by: Richard Smith <richard@metafoo.co.uk>
2.6 KiB
Remove Void
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
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.