I wonder whether it would be possible to retrofit Arena allocation transparently (and safely!) onto a language with a moving GC (which IIUC Go currently is not):
You could ask the programmer to mark some callstack as arena allocated and redirect all allocations to there while active and move everything that is still live once you leave the arena marked callstack (should be cheap if the live set is small, expensive but still safe otherwise).
Unlike opaquely financed and privately owned media companies, the Guardian is actually relatively clear and open in how it is financed and set up in a way to try to make them as independent as possible (see for example the Scott Trust's annual report https://uploads.guim.co.uk/2025/09/11/The_Scott_Trust_Limite...).
That's not to say that they don't run their fair share of gossip/clickbait... but show me an online medium that does not.
It's a question of energy density. Multiple joules into your big phone battery is nothing, multiple joules into a small SMD component means it evaporates immediately in a bright flash!
One of the oldest (AFAIK) occurrences of this was AOL releasing a data set of "anonymized" search queries in 2006 and it took a about a day for the first person to be deanonymized.
If there was a std::unit_t and it was implicitly convertible to optional, tuple and pointer, I don't think that would be worse in terms of usability at all (maybe worse in readability for people who haven't heard of a 'unit' type).
As for the std::variant use case, using std::monostate is only a matter of convention there. You could use any of the other unit types just the same.
What's really weird to me is not that C++ has a unit type and picked a weird name for it (that's just C++). The weird thing is how many unit types it has:
I find it annoying that (a) this seems to be a hardware feature that is almost universally permanently disabled in firmware and (b) it's almost impossible to find out whether it is supported by any given product (neither of the two products you link provide any mention on the spec sheet).
SD Express is basically dead as far as I can tell.
SD card users who care about speed have UHS-II equipment, but SD Express and UHS-II use mutually incompatible high speed signalling on the same pins (so cards and readers are only supporting one of the two - I guess technically this could be fixable with special purpose chips, but at large cost).
Users who care about speed but not about SD card compatibility are already using CFExpress, which is supported by most modern professional cameras and has much better hardware availability than SD Express.
Unless your 5 GHz spectrum is crowded by other WiFi, you really want to be on channel 36, because that way you do not have DFS at all, see the table on Wikipedia: https://en.wikipedia.org/wiki/List_of_WLAN_channels