I think he's arguing that C++ exceptions are unsuitable for parallel data processing, at least in cases where exceptions are regularly thrown.

If exceptions are regularly thrown the software has a bad design and must be fixed. Non-exceptional stuff must of course not be handled through exceptions - no exception should ever be thrown if the software operates as it is expected to.

There is the red flag: "regularly thrown". "Regularly" is opposite to "exceptionally".

Well of course, they are slow so they are unsuitable. The issue is whether they need to be slow.

No, he's arguing that he'd prefer it not be if that means breaking support for end user apps which is what the OP is arguing for.

No, of course not. But let's not change the language in ways that benefits those use cases at the detriment of more common use cases.

Of course, if there are ways to keep more or less the same semantics, while increasing performance, by all means it should be done !

for ones that throw an exception for 1% of a unit computation, perhaps yes.

But as has been noted, that's a lot of failures and exceptions may not be the appropriate mechanism to deal with this type of failure.

Indeed, arithmetic errors are what NaN was invented for. It still works, and is fast.