proposal: spec: checked integer types

[ianlancetaylor]

As a simpler alternative to #30209, I propose that we add a new set of integer types that panic on overflow.

First a quick summary of some other languages, to the best of my knowledge:

• C and C++: integer overflow is undefined.
• Java and D: integer overflow wraps. This is also what Go does today.
• Rust, Clojure, and Ada: integer overflow throws an exception.
• Swift: integer overflow throws an exception but additional operators wrap: &+, &-, &*.
• Haskell: integer overflow is implementation defined.
• C#: integer overflow may be checked or wrapped by using the checked and unchecked keywords.
• Python and Ruby: integers have unbounded size and cannot overflow.

Issues #19624 and #30209 argue that in Go integer overflow should panic. But today integer overflow wraps, and we cannot break existing code.

I propose that we add a new set of checked integer types. These will use a prefix o, for overflow. The types will be oint, oint8, oint16, oint32, oint64, ouint, ouint8, ouint16, ouint32, ouint64, ouintptr. We can also consider adding the type aliases obyte (= ouint8) and orune (= ouint32) although I'm not sure they are very important.

These new types act exactly like the corresponding types without the o prefix, except that if an addition, subtraction, multiplication, or division operation overflows, the result is a run-time panic.

Issue #30209 suggests adding a comma-ok form to detect integer overflow in an expression, as is also suggested in #6815. The main advantage of comma-ok for simple expressions is for a simpler implementation of multi-precision arithmetic, but for that use we have instead chosen to provide functions in the math/bits package. The main advantage of comma-ok for complex expressions is to permit switching between checked and wrapping arithmetic, but we already have wrapping arithmetic in the int type, and there is no realistic prospect of removing that from the language. So I do not think we need a comma-ok form. If there are other uses of comma-ok, this proposal still supports them, awkwardly, via a deferred function that calls recover.

There will as usual be no automatic conversion between existing types and the new types. This requirement of Go is the only way that this approach can work.

[beoran]

While this is a simple solution it doesn't seem to be the best solution to me. With my range types proposal, #30428, and use of type aliases, this simply becomes:

type OInt8 = range int8[math.MinInt8:math.MaxInt8]
type OInt16 = range int16[math.MinInt16:math.MaxInt16]
type OInt32 = range int32[math.MinInt32:math.MaxInt32]
type OInt64 = range int64[math.MinInt64:math.MaxInt64]
type OUInt8 = range uint8[math.MinUint8:math.MaxUint8]
type OUInt16 = range uint16[math.MinUint16:math.MaxUint16]
type OUInt32 = range uint32[math.MinUint32:math.MaxUint32]
type OUInt64 = range uint64[math.MinUint64:math.MaxUint64]

As per my proposal, panics are emitted on overflow, but the , ok form will also be supported. I think this issue goes to show that controlling the overflow of integers is indeed useful in several people's mind. But I believe it's better to build a generally useful language feature than a specific special case one. Therefore I think my proposal is the best approach to get general use range checked integers by implementing range types.

[josharian]

The “o” prefix is a bit odd, in that these are types that don’t overflow. I don’t have a better suggestion, though. “c” for checked, perhaps, although cint looks a lot like C.int.

[ianlancetaylor]

Yes, I considered a c prefix but I think it could be confusing. But I'm not wedded to o.

[extemporalgenome]

uint32p ? (the 'p' is for "panic"). I presume that int8(oint16(x)) may wrap around into the final int8?

And should a Go 2 derivative of this concept permit byte(256) to wrap around at compile time (not get compilation errors) while obyte(256) would have the present compile-time behavior? byte(obyte(256)) could be the way to get a compile-time evaluated byte that is "temporarily checked."

[josharian]

Maybe I’ve been hanging out on the wrong side of the C tracks, but I read int32p as “pointer to some int32”.

And if you put it as a prefix...well, seems like you’d need cup and quart as well.

“b” for bounded?

[beoran]

@extemporalgenome
I updated the spec of my proposal to add another check on overflow, during calculation based on the underlying type. The idea is that ranged types would not allow any overflow at all, not even during calculations based on the underlying type, but for performance the bounds check only happens just before the final assignment.

Your example int8(OInt16(x)) will cause a panic if X is out of range for OInt16. But if X is in range then the conversion happens based on the underlying types, then this becomes identical then to int8(int16(X)) which will wrap.

[alanfo]

I certainly prefer this proposal to #30209 which I felt was over-complicated.

My only reservation is whether this is a better way of solving the overflow problem than the wildly popular #19623 which (at the cost of some efficiency) gets rids of it altogether and also deals with requests for larger integer types such as int128. The only thing I didn't like about that particular proposal was changing the implementation-specific typesint and uint to be arbitrary precision. Unless there's a plan for Go to stop supporting 32-bit platforms in the near future, I'd prefer a new signed arbitrary precision type (zint say) instead.

Anyway, to return to this proposal, I agree that the o prefix seems inappropriate and c would be too confusing. Whilst b confers the correct sense the word bint has unfortunate connotations (see here). How about l for limited instead?

[bradfitz]

Rust, Clojure, and Ada: integer overflow throws an exception.

Kinda, but not really for Rust: https://doc.rust-lang.org/book/ch03-02-data-types.html#integer-overflow

When compiling in debug mode, Rust checks for this kind of issue and will cause your program to panic, which is the term Rust uses when a program exits with an error. We’ll discuss panics more in Chapter 9.

In release builds, Rust does not check for overflow, and instead will do something called “two’s complement wrapping.” In short, 256 becomes 0, 257 becomes 1, etc. Relying on overflow is considered an error, even if this behavior happens. If you want this behavior explicitly, the standard library has a type, Wrapping, that provides it explicitly.

[networkimprov]

@extemporalgenome suggested a suffix, which is logical, since bounding pertains to the bit count

intb
int32b
uint32b

[ianlancetaylor]

A suffix makes a certain amount of sense but I think it would be too easy to miss when reading the code.

[networkimprov]

Human perception finds words, not character strings, so a prefix letter is easily confused for identifiers with that letter sequence.

Certain letters or an underscore would be hard to overlook

intq
int32q
uint32q

int_b
int32_b
uint32_b