I'd accept that it's not the same as the empty type though, given that void* can be occupied and functions marked void can return. Probably someone with more type theory than me can name this properly
Probably “garbage”. C’s void is not a type and does not behave consistently, it’s a keyword associated with arbitrary convenient behaviours for that case.
void f();
void v = f();
void g(a){return a;}
v = g(v);
template<range R, regular X, invocable<range_value<R>, X> F>
requires same_as<invoke_result_t<F, R, X>, X>
auto fold(R&& range, F f, X accumulator) {
for(auto x: range)
accumulator = f(x, accumulator);
return accumulator;
}
enum class void_t { Void };
fold(my_range, [](auto&& elem, void_t) { return Void; }, Void);
fold(my_range, [](auto&& elem, void) { return; }, void{});
template<typename T>
T callWithState(auto f) {
auto old = globalState;
globalState = whatever();
T out = f();
globalState = old;
return out;
}
fn f() {}
let mut v: () = f();
fn g(a: ()) { a }
V = g(v);
Sure, it doesn’t do much useful to C save make void ever so slightly less wonky.
If following something like CQS the bifurcation can be thought of allowing “pure” functions and excluding code with a temporal / side-effecting component from higher order code.
Not saying bifurcating on void is the best approach to handle that, but in languages where side effects are a thing something is needed to make sure higher order code and side effecting code mix properly.
And this doesn’t come anywhere near to properly making that distinction anyway: a non-void function can have all the side effects, and a void function can have no side-effects.
It also does not “make sure higher order code and side effecting code mix properly”, it just makes a subset of likely side-effecting code not mix with higher order code at all.
The compiler does not allow you to do that particular operation out of an arbitrary restriction, but that does not make `void` a true void type. It still holds a monotype value!
int bar() {
std::cout << "Bar" << std::endl;
return 0;
}
void baz() {
std::cout << "Baz" << std::endl;
}
template <typename T> T foo(T (*f)()) {
std::cout << "Foo" << std::endl;
return f();
}
template <typename T> T varfoo(T (*f)()) {
std::cout << "Varfoo" << std::endl;
T a = f();
return a;
}
int main()
{
foo(bar); // Valid (returning an int).
foo(baz); // Valid (returning a void).
varfoo(bar); // Valid (assigning an int).
// varfoo(baz); // Invalid (assigning a void (why???)).
}In C++, there's a very compelling case for making void an actual type, because you can't use void as a templated type, which means that templates involving functions that potentially have void return types require unpleasant amounts of template metaprogramming.
Now that C++ standards committees are considering basic usability fixes (e.g. the long overdue ability to do`namespace com::microsoft::directx { }`) there's a vague possibility that somebody might look into actually fixing this some time before 2040.
C++17 and C++20 both took up usability fixes. std::string::ends_with would be a a C++20 example.
Hopefully C++23 will be similarly open to usability fixes.