Regular void [LWN.net]

Regular void

Posted Sep 10, 2026 10:24 UTC (Thu) by ralfj (subscriber, #172874)
In reply to: Regular void by tialaramex
Parent article: Stabilizing Rust's never type

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...

to post comments

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++.