Apologies if I did not pick up any original sarcasm.
I was confirming that yes, the hardware implementation of the math operations is to proceed with the safety net being an interrupt on issues. This hardware implementation has improved performance and memory usage.
We already have operators which can be used in cases where a developer must use 'safe' operations due to potential overflows. These have an impact - my point was that all of the approaches (throwing, optional, boolean indicating overflow) when done in library space have similar performance impacts.
The end user does not care why the developer's application crashed, no. They do care that the issue is fixed, and a crash report which indicates exactly where the math failed will help the developer accomplish that. This is a consistent decision in Swift design.