[acqq]

> That they exist is not the problem. That they exist _and_ don't provide enough performance is the issue. That is, your "no cost" is what I'm asserting here, not that it doesn't exist at all.

I'm claiming that the machine instructions exist to implement at no cost this high level construct (using C-like syntax):

    if ( overflows( c = a + b ) ) {
    }

What people say to produce slowdowns is if they want to implement

     try {
          a huge bunch of instructions where some are additions
     }
     on integer_overflow_from_wherever do whatever

The former is no cost if implemented, and exists in every CPU. The later doesn't exist, but who says that only later is what has to exist? Why not implementing the no-cost former?

> It still has some C code today

Exactly my point why curl has no reason to be reimplemented in Rust now.

[steveklabnik]

> I'm claiming that

This is different than the claims that were made when we made this decision. Specifically, the cost angle. You can absolutely do this, but we don't turn it on by default due to its expense. See https://danluu.com/integer-overflow/ for example. From that link:

> Summing up, integer overflow checks ought to cost a few percent on typical integer-heavy workloads

That few percent matters. And the extensive discussion (in both directions) on HN: https://news.ycombinator.com/item?id=8765714

It would be reasonable to turn it on, but that's not the decision we made.

> Exactly my point why curl has no reason to be reimplemented in Rust now.

Again, I never said curl should be ported to Rust.

[dbaupp]

FWIW, the former "no-cost" thing does exist in Rust, in the form of "checked_..." methods on the various integer types, e.g. https://doc.rust-lang.org/std/primitive.i32.html#method.chec... .

[acqq]

Thanks! That's the good approach.