The team that created Pages, before that they were GoBe Productive for BeOS, and before that Clarris, so Pages is their 3rd or 4th redesign from scratch.
For most domains, it is fine. Why should my valued checked code pay the price for checking every arithmetic operation for overflow. Why should my correctly implemented algorithm waste CPU checking something I know is valid? And worst of all, what happens when a logic error is encountered, we run untested code path? I hate code that is conditionally defensive (eg. if (ptr) ptr->critical(); ). I should never be in that situation, a silent ignore corrupts internal state, and never tested the fail path. Ptr may even refer to garbage. Its a stupid defebsive check in 90% of code bases. std::optional<Ptr> at least clarifies intent.
The problem is that it silently overflows by default - and a good chunk of the time it is even undefined behavior. Sure, in some situations you as the developer are 100% certain that an overflow is impossible (despite the compiler not being able to prove this and therefore eliminate the checks), but in the vast majority of cases it is a footgun silently waiting to go off.
Rust tries to solve this by having basic addition panic in debug, while silently-but-consistently continuing in production: overflow is considered a bug, but it is at least not a platform-dependent bug.
If overflow is expected, then there's checked_add to detect it and fail in a friendly way, saturating_add / wrapping_add / carrying_add for specific overflow behavior.
Finally, if speed is crucial and overflow is either impossible or you don't care about the outcome whatsoever, there's unchecked_add to explicitly opt-in to a C-like "just do whatever the machine feels like".
You can still do everything you can with C. It it just an explicit choice, rather than an implicit platform-dependent mechanism you might forget about.
> unchecked_add to explicitly opt-in to a C-like "just do whatever the machine feels like".
Just like for signed integers in C the {integer}::unchecked_add is Undefined Behaviour if overflow occurs. So that's not "whatever the machine feels like" it's much worse.
This is an unsafe function, so you're expected to write a SAFETY rationale for the unsafe call, and that's your opportunity to justify to a future maintainer why you were sure this addition never overflows. If you find yourself struggling to justify that belief it probably means you should not have used this function.
If you're going to write guard code for overflows, and use that to justify the SAFETY claim, why not use the existing functions for that? Clippy will suggest this in many cases because it's less likely you will blow your own foot off.
No one is suggesting that every arithmetic operation is checked for overflow. The suggestion is that overflow is not undefined behavior. Getting rid of undefined behavior for overflow does not in anyway require that every operation is now checked, all it requires is specifying that the result of an arithmetic overflow depends on the platform and different platforms might produce different results.
Defining the behaviour for overflow in the language doesn't suddenly mean the behaviour is what every program wanted. Fine that it has a defined result, but if that result isn't what you meant when you wrote a+b it's still a bug.
At a broad view, we get to a place where there's no "bug" when "what happens on overflow" is what the program(mer) wants.
I have no idea how to parse your comment or how it relates to what I said.
All I said is that you can remove undefined behavior from signed overflow without having to introduce checks to every arithmetic operation and without having to specify any particular behavior or outcome. The technical term for this is "unspecified behavior" and the consequence of making overflow unspecified behavior is that the consequences of overflow, while still unspecified, must be bounded in space and time, unlike undefined behavior whose consequences are not required to be bounded in either space or time.
I mean removing undefined behaviour from signed overflow isn't the problem. The problem is that when a programmer previously wrote a signed operation that could overflow, they didn't specify what behaviour they really needed.
You can define a behaviour today that they'll all get, but you can't define a behaviour that matches what each programmer needed when they wrote their operation. Some of them can wrap safely. Some of them would need to saturate. Others would need it to abort.
The problem isn't that the behaviour is undefined per se, it's that you can't tell afterwards which potential behaviour the programmer needs, and choosing one behaviour e.g. wrap will break everyone who actually needed saturating, or trapping, etc.
I like the Employees Wash Hands sign. Recent batches of API tools seem focused on sanitizing IO: WebMCP, AI strings, safe native input parse, even Assembly mapping. So in a hot loop (whatever F35 anonymous lambda) you may have data change under you. So on antiquated hardware (like a Voyager I) maybe you want to flash the firmware to 3.5 after 70 years... but Iran has a HELLIOPARSER. It's imperative to be defensive transmitting data streams across the light years.
It makes big companies and gov bodies happier since and code investment is guaranteed to run with competitors tool chains. You’re not locked in to one vendor, it is an international spec.
Until you want to do something as simple as export a function from the dll/so. The syntax and stdlib may be standardized, but that's not enough to make a language portable.
C allowed pointer aliasing, so you always have to refresh reads incase a pojnter modified the value. With any loop, that is just more reads to update dependancies every cycle. When not aliased, you cache value in register. Much later C introduced “restrict” keyword to match fortran performance code. c++ is still fighting this by insisting you work with different types, hence by default you dont get aliasing but that doesnt cover 100% of scenarios.
My take is that it is an exciting time to be a mathematician since the frontier for interesting math problems is about to explode, and without prior art or references, it's green field for both AI and human. Think of all the new discoveries we'll make.
Ah yes, more enshitification. The other day Visual Studio 2026 brought in a mandatory update, lots of CoPilot stuff I didnt ask for, but they broke code search so finding who uses a structure is now harder to find. No way to revert to older version of VS2026.
I am sorry but what does cache locality and CPU core access pattern(s) have to do with the video you linked? Indeed it shows a lot of instances in animation, but the only technicalities it mentions are bare mention of Vulkan (which I assume implies GPU), and I am using the CPU and without any libraries.
reply