Regular void [LWN.net]

Regular void

Posted Sep 10, 2026 9:57 UTC (Thu) by tialaramex (subscriber, #21167)
In reply to: Void is surprisingly useful. by ralfj
Parent article: Stabilizing Rust's never type

In C++ this idea that their void should be a unit type often comes up as "Regular void" to distinguish this from the present status that void is irregular because it is treated as "incomplete" in their language whereas a pointer to void is an actual type.

Here's an example of a "Regular void" proposal for C++
https://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p014...

But while "regular void" is superficially attractive, it can't really work in C or C++ and that proposal illustrates some of the difficulty and I'm sure responses when it was presented get into some others.

Basically C has a crap type system and C++ mostly makes things worse rather than better, a "regular void" might be a reasonable patch in a good type system, but in C++ it just substitutes one set of crazy edge cases for a different set of crazy edge cases.

to post comments

Regular void

Posted Sep 10, 2026 10:24 UTC (Thu) by ralfj (subscriber, #172874) [Link] (4 responses)

Fixing such an early mistake in a language with a huge installed base is indeed hard. Rust made the right call with () (our void equivalent) from the start, but we made ! not-a-type initially and it took us 10 years and I don't even remember how many attempts to fix that...

Regular void

Posted Sep 10, 2026 11:05 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (3 responses)

I used to have a lot more sympathy for the "It's hard to fix" people before I saw how hard WG21 worked to shoot down Epochs (an attempt to give C++ a feature like Rust's editions, after seeing it work just once in 2018 Edition) and Sean's "Safe C++" work and read JeanHeyd's lengthy battle to land #embed in C at WG14

These are not people who tried hard to improve the language but were foiled by how difficult it was to deliver because the language is very old, they're people who didn't want to change and found every excuse possible for why everything must remain exactly as it is. Computer Science is a young discipline, and I'm an old man, but this sort of thing is how we get that saying "Science advances one funeral at a time".

Regular void

Posted Sep 11, 2026 17:49 UTC (Fri) by wahern (subscriber, #37304) [Link] (2 responses)

Well, #embed has already had to undergo revision shortly after standardization in C23: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3912.htm Even the simplest features can be tricky.

Granted, the headaches come from C wanting to support some degree of source-level compatibility with C++, as well as having many implementations, including multiple *major* implementations. These are headaches languages like Rust don't have to deal with. An implementation quirk in Rust can just become the de facto standard, or supported as hack through backward compatibility features. But when you have multiple implementations that diverge, there's no tidy way to fix that mess.

Regular void

Posted Sep 11, 2026 18:58 UTC (Fri) by mb (subscriber, #50428) [Link] (1 responses)

>wanting to support some degree of source-level compatibility with C++

Not having an FFI between C++ and C is a major problem.
Having it would free C++ from many of the compatibility problems.

It is fixable by introducing it in a new standard version.
But there does not seem to be willingness to do it - I presume - as it would complicate programs that mix C and C++ willy-nilly

Regular void

Posted Sep 11, 2026 22:51 UTC (Fri) by wahern (subscriber, #37304) [Link]

Almost certainly will never happen. My impression is the committee avoids name mangling like the plague. And name mangling aside, I assume there's a host of other thorny issues regarding parameter passing (e.g. references, implicit this, etc) that nobody wants to tackle. Is there any prior art? I don't remember GCC or clang having any extensions to help calling into non-extern-C C++.

Regular void

Posted Sep 11, 2026 22:04 UTC (Fri) by magfr (subscriber, #16052) [Link]

When I read this I thought it looked more like the proposed bottom type of P3549R0.