quuxplusone

Yep; but a parameter is one of the special "safe" cases where the variable's lifetime is guaranteed to be shorter than the lifetime of its initializing expression. Other "safe" cases are catch-handler "parameters" (not that it makes much sense to catch a string_view) and for-loop "parameters" — i.e. `for (string_view sv : stuff())`. The most relevant of these cases by far is the case of plain old function parameters.

These are cases where the core language helps the programmer out, and basically makes a whole class of bugs — well, not impossible, but difficult to run into if you're not actually trying. There are other cases, e.g. `string_view sv = stuff();` as used in TFA, where the core language offers no help at all, but there's an easy solution available. ("Don't do that, then." Treat `string_view` as a "parameter-only type" and you'll never encounter that kind of problem.)

And then there's C++20 coroutine "parameters," where the core language pretty actively tries to trip you up. https://quuxplusone.github.io/blog/2019/07/10/ways-to-get-da...

This is why I call string_view a "parameter-only type": it's fine to take as a parameter, but not fine to return or to store as a variable. (For sane definitions of "fine" and "not fine," of course. The blog post demonstrates one way it can go "not fine.")

https://quuxplusone.github.io/blog/2018/03/27/string-view-is...

The hex grid (rather than, say, square, or random Voronoi regions). The fact that some hexes have 1 voter and some have zero (rather than, say, all hexes having 1 voter, or any having more than 1). The circular colored dot indicating the voter's party (rather than, say, a picture of a horse, or tinting the entire hex). The "Hint", "Reset", and "Submit"/"Call election" buttons below the grid, in that specific order; and (I assume) the nature of the hints. The "health bar" graphic depicting the number of horse voters and donkey voters.

The point of choosing Kevin Bacon in the first place was that "Kevin Bacon" sounds roughly like "separation," so the reference works. AFAIK there was no additional criterion.

std::vector does. No other container cares about noexcept at all.

https://stackoverflow.com/questions/66459162/where-do-standa...

Background: https://quuxplusone.github.io/blog/2022/08/26/vector-pessimi...

> The C++ container classes assume noexcept constructors for this reason, because creating a list of size 20 calls your constructor 20 times, and the cleanup gets so much messier.

No, STL containers such as std::vector definitely do not assume (nor require) non-throwing constructors. They just do the right thing. Yes, cleanup is messier than it would otherwise be.

STL containers do require that your destructors not throw (but do not require that they be noexcept).

I don't see how most of the plot holes/unrealism you identify is connected with the Butlerian Jihad at all. But re "critiquing Dune's idea of future warfare" (shields and knives, ornithopters, etc) you might also be entertained by Bret Devereaux's recent take:

https://acoup.blog/2026/02/24/collections-warfare-in-dune-pa...

I have no special information, but it could just be Amdahl's Law. If one guy (or bot) checked in 5GB of binaries before you thought to enable git-lfs, then that's not a 100/25 ratio, it's a 95/20 ratio. And if it was 10GB, that's a 90/15 ratio, and so on. IIUC, the old un-LFS'ed binaries remain in the history unless you actively `git lfs migrate` and rewrite your whole history, which they might not want (or care enough) to do.

Gerrymandle, although it's started the slow slide into ads and popups in the past month. https://gerrymandle.com/puzzles

saimiam's comment mentioned 2048, so I'll plug my variant:

https://quuxplusone.github.io/2048

Yes, that's a good (and shorter) way to put my complaint. :)

For all I know, perhaps this even was guarded by such a link, but because I got to it through HN, I would have missed the warning.

FWIW, I wish you'd spent a few minutes cleaning up the first dozen pages of Claudespeak. You have some human text at the bottom of the post, but first you force your readers to wade through (or skim, or just close the tab) stuff like "Solver experiments show the bare rule is loose" — "is a chore with the shape of a puzzle:" — "test candidate mechanics on thousands of random gardens with an exact solver, a constraint-programming optimizer, and a deductive difficulty grader" — "the only U-turn-free raking among 12 par rakings of 6,310,226. Ripple stones and wave bands, the obvious “pattern” constraints, add texture but not tightness" — ...

You do see how that's all garbage, right? So why not just delete it? Keep the good part, delete the bad part.

The game widget itself takes up 3 pages on mobile, because of all the Claude web design.

... Wait, as I scroll down again in composing this complaint, I realize I'm wrong about there being any human text at all. It's all garbage. This makes me kind of sad for the Gwern we've lost.

> I'd be very surprised to learn that GHS had ever developed their own frontend.

Actually I take that back. At the dawn of time (1982), GHS definitely had its own frontend. They switched to EDG sometime before my time. I meant I'd be surprised to learn they'd switched from EDG to something home-grown.

This also meant that in my time there was a hefty "glue" layer between the EDG frontend and the GHS middle-end (the middle-end being the tree transformations and "indep" optimizations before you got into the back-end stuff): you had to take the structures EDG produced and turn them into the structures the GHS middle-end wanted.

I was there right when John Regehr's Csmith was first making big waves. We started using it, and also rolled our own fuzzer with more focus on embedded-software trouble spots, such as `volatile` and `packed` and I forget what else. (Guy Goldstein originated and led this, as I recall.) I don't actually remember the fuzzer finding a lot of crashes, but maybe it did, and I do remember its finding a lot of miscompilations, i.e., bad optimizations.

In my day (2006–2011) Green Hills used EDG's frontend. I have the vague impression they might have already switched away. (I know Intel ICC already switched to Clang a while ago.) I'd be very surprised to learn that GHS had ever developed their own frontend.

You Gotta Have Wa, by Robert Whiting (1989), about baseball in Japan in the 1980s.

Frankenstein, by Mary Shelley (1818/1831), https://frankendiff.com; and Tales of the Dead, by Mrs. Utterson (1813), https://archive.org/details/talesofdead00utte

Just started Homer's Iliad (Fagles translation) and Christopher Logue's War Music (2015).

Just finished re-reading The Hitchhiker's Guide to the Galaxy, by Douglas Adams (1980). I think it holds up well. Last time I read it, I was much younger than Arthur Dent; now I'm much older. And now that we have computers with Genuine People Personalities, it's hard to remember what it was like in the Before Times.

Recently finished Gaston Leroux's The Mystery of the Yellow Room (1908). For better or worse (no spoilers here), it kept me guessing.

Perhaps relevant to this audience: NetHack has a routine specifically for this.

https://github.com/NetHack/NetHack/blob/NetHack-5.0/src/objn...

I think I agree with the comment in NH5 that some of the new cases "probably shouldn't be handled here", and think maybe NH3.4.3's simpler version should've been fine for NetHack's purposes:

https://github.com/Vanilla-NetHack/NetHack-3.4.3/blob/master...

Highly recommend on this subject John DeFrancis' "The Chinese Language: Fact and Fantasy" (1984)!

https://archive.org/details/chineselanguagef0000defr/

I dunno, I've never done what TFA suggests, but it makes sense to me. The idea isn't that your new foo.go file would be ignored by default; it's that your Go project's repo's .gitignore file would start with * and then !*.go , so that your new foo.go file would show up as untracked-and-unignored but your new foo.go.sav~ and .DS_Store and .foobarrc files would not.

Maybe that's more ergonomic than forcing all users to learn about ~/.gitignore or manually adding .DS_Store *.sav~ et cetera into your Go project's repo's .gitignore.

What is this AI-generated gobbledygook actually trying to say? That there are infinitely many pairs of primes p,q with q=p+186?

The first equation under "The result" seems to be saying they found an infinite sequence of primes whose density is forever greater than 1/186, which doesn't match my understanding of how prime density works.

The problem is that "predictable reliable NRVO" is still a research problem. Real-world compilers do NRVO a lot but not in a way that is perfectly predictable — that is to say, not in a way that could be standardized across all compilers (or even between different releases of the same compiler).

A "perfectly predictable" algorithm was proposed in Anton Zhilin's P2025, back in the year 2021: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p20... but unfortunately it had some subtle corner-case problems (which I do not remember), so it was sent back for revision, and never returned with a fix. (Maybe because a fix wasn't possible; again I don't remember what the deal was exactly.)

The Right Path Forward would be for MSVC, GCC, and Clang all to try implementing P2025's algorithm in their front ends. Either something concrete breaks (reminding me what the problem was), or else all three mainstream compilers gain predictable NRVO and then we can "standardize existing practice." But the Right Path Forward requires tedious work by at least three people, which is hard.

Yeah, the second one is supposed to read `Apple&& Cat(Apple&& val) { return val; }` — but the return type's `&&` was omitted by accident.

Douglas Hofstadter, Le Ton beau de Marot (1997), pages xviii–xix:

> Because I have always had a very clear sense of how thing should look on a page, I dearly wanted to be able to control every tiny detail of my book's overall look, ranging from the cover art to the typefaces used to the size of the pages to the way displays are indented, and so on. Fortunately, the people at Basic Books have grown used to me and my idiosyncrasies over the years I have worked with them, and they assented to my unusual request.

> [new page] Consequently, I have enjoyed total control over such things as line-breaks, page-breaks, hyphenations, widows, orphans, density of word spacing within lines, fine-grained intercharacter spacing ("kerning"), and so forth and so on — things that most people usually are unaware of and simply leave to their publisher or their word processor. I am a fanatic, though, and these things matter a great deal to me. Not only do they matter to me, they have had an overwhelming impact on this book from start to finish. This may sound crazy, but it is the gospel truth.

> [section heading] Who Is Really Controlling Whom?

> Above, I very casually remarked that I have enjoyed total control over page-breaks and such things; yet the truth of the matter would be far more accurately captured by turning the phrase around and saying that the page-breaks and word spacing and such things have enjoyed total control over me! By this, I mean that I have been forced to rewrite and rewrite and rewrite passages in order to make a page boundary come out exactly where I wanted it. It is not just by some happy accident, for instance, that the poems inside chapters are never, ever broken across page boundaries.

> The amount of influence exerted on my text by concerns of purely visual esthetics is incalculable — and by "my text", I don't merely mean how I wound up phrasing my ideas, I mean the ideas themselves. Content has been determined by considerations of elegant form so often that I couldn't begin to imagine it. Every single line of text, for instance, is characterized by its spacing — how wide the blanks between words are. I can clearly see the spacing as I type on my screen, and I rewrite and rewrite in order to make sure that no line is too tightly or too loosely spaced. In the course of such rewritings — here extracting a word, there using a shorter or a longer one, elsewhere inserting a word where none was — words and phrases that I would otherwise not have thought of pop to mind, suggesting ideas I would not have thought of, and those ideas suggest unexpected paragraphs, and those paragraphs are in turn linked to other ones, and so on...

Yes. This is what one wants, since if you have recently rebased it, you're clearly doing work with it. Meanwhile, branches you don't care to touch sink to the bottom of the list.

> One speculative interpretation treats these numbers as a distorted memory of prehistory. Under this hypothesis, the reign boundaries encode real climate shifts...

"One theory" implies that someone somewhere has ever claimed this. But has anyone? TFA gives no source for the claim, AFAICT (although I skimmed a bit).

Because English. If you're writing a data file and one row of data elements is like "one, red, 3.14, Tuesday," why wouldn't you write exactly that in your ASCII text file? And when you do, that's CSV!

And that book is (naturally enough) borrowable on archive.org. :)

https://archive.org/details/policemansbeardi0000unse/page/n2...

I was thinking that "I come alive with 0 neighbors" wouldn't make a sensible rule: it's not reasonable to have the whole universe strobing on and off every clock tick.

But "I stay alive with 0 neighbors" probably makes sense, so okay, multiply what I had said by another factor of 2 and call it 17 bits total. :)

Cleopatra was a contemporary of Julius Caesar, and played a major role in his biography. (Which is why Plutarch wrote about her, which is why Shakespeare wrote about her, which is why 20th Century Fox made the film about her.) Julius Caesar is... a big name... in the West. Call that "the effect of media" if you like, but it's a thing.

Hatshepsut and Nefertiti lived respectively 1400 and 1300 years before Cleopatra, and about 700 years before even the founding of Rome. I'm no expert, but seems to me that those two names completely disappeared from the historical record between say 1000 BC and AD 1800, and were rescued from obscurity only by 19th-century archaeologists.

And that book is (naturally enough) borrowable on archive.org. :)

https://archive.org/details/policemansbeardi0000unse/page/n2...

+1. Tom Di Mino hasn't posted anything on https://www.linkedin.com/feed/update/urn:li:activity:7471395... since June, nor has Stephen Kosloff posted anything more on https://aiclambake.com/clamtakes/ . I wouldn't expect any updates on that story.

As for Linear A decipherment claims, claiming decipherment isn't the same as decipherment. For example, here's a claim from 2014 that Linear A encodes spoken Japanese: https://konosos.net/2014/12/09/the-phonetic-method-in-linear... Does Linear A encode spoken Japanese? of course not.