This story is one of only a couple sci-fi short stories to creep me out enough that I still remember them vividly decades later. (John Varley's "PRESS ENTER ■" is another.)

> A man is twice the age his wife was when he was the age she is now. When she reaches his present age, their combined years will be 100. Find the age of each.

This seemed initially like something amenable to guessing and checking a few ratios. It was not.

My answer: The man is 44 4/9 years old, the wife 33 1/3 years.

Passing for now.

Hard errors up front are great when you control the full content pipeline. It's very rare that that's the case, and was rare even in 2004. As soon as including someone else's broken content in your page prevents users from seeing your content, and that someone else can break the content at any time and you can't control it... few people will want hard errors.

I also used to work on a production C compiler. Compilers can and do "guess what you meant" in various cases, notably for producing actual human-readable errors or proceeding past various warnings, but if I recall correctly even in more obscure non-error cases.

Hyrum's Law is a real jerk sometimes.

Asking "who wrote this stupid code?" will retroactively travel back in time and cause it to have been you.

The short summary, though, is that no toolchain yet has a bulletproof implementation, though everybody at least has enough to let people kick the tires a bit.

In Chromium's UI code, we have a lot of APIs that deal with coordinates, which may be in either px or dp. And we have a lot of code that needs to hardcode various constants, e.g. layout values for different dialogs. IMO, it's sane to have UDL support here, e.g. `20_px` (at least if we had separate types to represent these two things, which we don't... don't get me started).

I suspect if I dug into the archives, I'd find a discussion on cxx@ with some comments about how doing this would result in some esoteric risk. If I was still on the Chrome team I'd go looking and see if it made sense to reraise the issue now; I know we had at least one stable branch security bug this caused.

Anyway, I think there are two takeaways:

1. There probably do exist non-8-bit-byte architectures targeted by compilers that provide support for at-least-somewhat-recent C++ versions

2. Such cases are certainly rare

Where that leaves things, in terms of what the C++ standard should specify, I don't know. IIRC JF Bastien or one of the other Apple folks that's driven things like "twos complement is the only integer representation C++ supports" tried to push for "bytes are 8 bits" and got shot down?

There are cases, however, when the migration costs are significant enough that even those benefits aren't really enough. Migrating our date/time stuff to seemed like one of those.

Some notable exceptions: we'd have allowed std::shared_ptr and . We might also have allowed and friends.