proposal: Go 2: new type: integer range constraint

[viper10652]

Context:
When certain data types are known to only have a limited set of values, then it is only possible to test for these dynamically in the current Go version.
It should be possible for incompatible types to be tested statically at runtime.

Proposal:

I can think of two ways to specify a constraint on the possible values of an integer type:

1. as an enumeration (has been proposed in other proposals, won't repeat here)
2. as a range

E.g.
type MONTHS range 1 ... 12
type DAYSOFMONTH range 1 ... 31
subtype DAYS_OF_FEBR of DAYSOFMONTH range 1 ... 28
subtype DAYS_OF_LEAP_FEBR of DAYSOFMONTH range 1 ... 29

when I receive a value of type DAYSOFMONTH
then I would like to test if it is valid for a subtype.
E.g.
var birthday DAYSOFMONTH
birthday := 14
if birthday in DAYS_OF_LEAP_FEBR { ... }

This concept exists in the Ada programming language.

There needs to be a conversion capability to convert non-constrained integer types to and from constrained integer types (range or enumeration).
This is useful when decoding and encoding between binary data received over a communication link and logical data.

E.g.
var b1 int
var b2 int
var f DAYSOFMONTH

b1 := 14
f := b1 // potential out-of-range
b2 := f // should be safe

conversion from constrained types to unconstrained should not be a problem
conversion from unconstrained types to constrained can result in an error.
Assignments that can cause an out-of-range condition need to be accompanied with an error assignment. The compiler can enforce the use
E.g.
var err error
f, err := b1 // when out-of-range, f is assigned Nil

[CAFxX]

While I like the idea, I think you could make a much stronger case by staying completely clear of dates/times in your examples.

[mvdan]

Also note that the compiler now has a "prove" pass that can keep track of the numeric ranges of integers. For example:

func Foo(s []byte) {
    if len(s) < 10 {
        _ = s[4] // no bounds check
    }
}

So I wonder - would this actually help in that many situations?

There are also languages like wuffs, which specialise in these kinds of static checks. It must statically prove that integer and buffer overflows are impossible, for example. And in the future it will support generating Go code, too.

[jimmyfrasche]

I brought up similar idea in #19814 (comment) (toward bottom of comment).

[networkimprov]

See also my comment here: #28987 (comment)

Which probably should be a separate value constraints proposal. Note its use of type aliases and values already defined in existing code...

[bcmills]

This proposal is missing an essential detail: what happens to ranged integers if they overflow the declared range? (When, if ever, are those overflows checked?)

[josharian]

This has been discussed a bit at
#19814 (comment) and surrounding comments. (Note that that is a very long thread, which GitHub has auto-collapsed, and frustratingly when you link into the middle of a collapsed thread, GitHub does not auto-expand it for you. So you'll have to manually expand the comments. Search in the page for uint12. Sorry about that.)

[beoran]

Ranged numbers are a great feature also found in Pascal and Ada, which help programming more safely. The Go compiler already has a range check for arrays, and this could be used to prove at compile time that a variable's value stays within range.

The month example given is not so compelling, but I know a few life critical systems where range checked numbers would help immensely.

If the compile cannot statically determine that a value stays within range then a result, ok or result ,err should be mandatory for the expression in question so a run time check can be introduced. Or, a panic might be raised as it is today for array indices.

[ianlancetaylor]

I note that the proposal mentions subtype, but there is no such explicit concept or keyword in Go.

What problem is this solving?

What happens when adding two values of the same range type? If the sum is outside the range, does the program panic?

What about multiplication between two values of the same range type? What about multiplication by an untyped constant?

type R range 3 ... 7
func F() {
    // What happens with the final i++ here?  When it goes to 8, do we panic?
    for i = R(3); i <= 7;  i++ {
        // do something
    }
}

[griesemer]

Along the same lines of what @ianlancetaylor already mentioned: Integer range types such as you propose and which were popular in languages such as Ada and Pascal were not picked up in successor languages. There are reasons for that. In fact, successful programming paradigms tend to get copied enthusiastically by newer languages, exactly because they do solve a problem and make programming simpler or better in some important way. One of the key criteria when we designed Go was not to include known language features that didn't pass the test of time.

It turns out that integer range types, while they sound really nice in theory, tend to make programming harder. As somebody who has programmed several years in Pascal, I can attest that problems such as the for-loop question above do occur. There are various solutions around the problem, and one of them is for the compiler to not check the range (which is what the Pascal compiler I was using did); of course that defeats the purpose. Then there are all the questions about (mathematical) closed-ness of the type regarding operations (what happens when I multiply elements of a range integer, etc.). Such operations are at best ad-hoc defined and ranges may not be enforced by the compiler (because it's too expensive). And if the ranges are enforced, people won't use those types because they are too expensive - they just use integers.

Even in existing Go, we find that it's often better in APIs to stick to int rather than uint (even though we know a value cannot be negative) because it makes interaction with existing code much simpler and doesn't require conversions.

I summary, I am not in favor of this idea.

[beoran]

About successor languages, far as I know Modula-2 Modula-3, and Delphi also have ranged types, Oberon does not include them but has a SET type in Oberon 2 which is quite similar except that the lower bound is always 0. So I disagree that this feature was not widely copied in successor languages.

I agree that range types are pointless if the range is not checked. Which is why, like in ADA, range types should be range checked on every operation, and either panic with a recoverable panic at run time, or give an error at compile time if the compiler can statically check that the value will be out of range. An extra result, ok := form on any operations involving ranged types could also be handy.

The argument that range checked numbers will not be used because it is too expensive is true for Pascal, certaly FreePascal where you have to explicitly turn it on with the {$R+} compiler instruction. But it is not true for Go, where we already have mandatory array index range checking and have a whole mechanism to make the compiler omit the checks if possible, thus limiting the performance impact. This feature would be very similar to array indices. Range checking on array indices is one of the features that makes Go a safer language than C or FreePasal. I feel that ranged numbers would likewise help Go to become an even a safer language.

To solve the for loop problem, I propose that for a type Foo range(A..B) the range keyword could be extended like this: for i:= range Foo, or for i := range range(A..B), and then the loop will iterate from A to B inclusive, where range checks can be omitted because now i is guaranteed to be in range unless operated on in the loop.

As for what the use case of this feature is, this would be for making Go more suitable for implementing software where safety is more important than interoperability. For such programs it is often crucial that certain variables can have only certain values that are within operational range.