Declare variables with valid range?

BryanQuigley · 2014-12-19T15:46:56.795Z

It seems like a natural extension of how variables (immutable by default, mutable if specified) are defined to allow the programmer to dictate a specific range of allowed values for an integer. If I know a value is only valid between 0-1000 the sooner I declare that the better it is for catching bugs, off by one errors, and more…

I’m not sure what exact syntax would work, maybe:

let mut(0,1000) x = 0i;

x is only valid from 0-1000 inclusive.

Thoughts?

tupshin · 2014-12-19T15:55:45.486Z

This would require bounds checking (http://en.wikipedia.org/wiki/Bounds_checking) on every calculation, but that is a not unreasonable tradeoff in many cases.

Uther · 2014-12-19T16:16:40.207Z

This RFC suggested range checking, but was not accepted (too complex) :

github.com

rust-lang/rfcs/blob/61969f5cbbfc5d79510419b62a766b05e76d88b3/active/0000-no-integer-overflow.md

- Start Date: 2014-04-14
- RFC PR #:
- Rust Issue #:

# Summary

Current Rust makes no attempt to be safe against integer overflow, and for the most part simply reuses the same integer semantics C has. While this doesn't necessarily cause memory unsafety, it still results in a language such that the programmer cannot be fully confident that programs written in it will work properly.

This RFC discusses a few options, and then proposes one, explaining a new idea to make it workable.

The goal is mostly to present this idea, and not to provide a final design.

Note that some of the formulas may be wrong, as they have been minimally reviewed, but hopefully it's easy to get the intuition behind them.

# Alternatives

## Change nothing

Changing nothing has the issues that the current u32, i32, etc. types are used as if they were integers, but they instead mostly behave like elements of the Z/(2^K)Z finite ring.

This file has been truncated. show original

mrec · 2014-12-19T18:21:34.228Z

Doesn’t Rust have enough support for operator overloading to be able to build a reasonable RangedNumber library without needing explicit language support? That seems to have been enough for C++ users over the years. I suppose it might be nice to have range checking for the builtin types available in debug builds, but I’d be very wary of putting a range constraint in code with no guarantee that it’d be enforced in any way.

Twenty years ago when I did some work in Ada for 68020s, it was general practice to put range constraints on everything that moved. I don’t remember anybody ever questioning it, even in a fairly performance-sensitive environment, but I was very wet behind the ears at the time and don’t know how many real bugs this caught in practice.

comex · 2014-12-19T20:14:09.534Z

Not if you want to encode the range in the type, since generic arguments can’t be values. (Well, not without some nasty hack way to encode a number into a type. When constants as associated items are implemented, it won’t be as nasty, though…)

seanmonstar · 2014-12-19T21:57:12.686Z

For smallish types, you can use an enum to restrict possible values. But it gets unwieldy as the range gets bigger.

fan-tom · 2017-01-14T07:59:12.235Z

If bounds checking would be performed in runtime, it is not Rust way (zero-cost abstraction). But elsewhere it requires dependent types support and compiler must prove type safety in that case by proving each usage does not try to access value out of bounds. Type checking in such type system may be undecidable, because you cannot even prove equality of two types if they depends of runtime values (function that return list of words it read from stdin, what return type it may have?)

kornel · 2017-01-16T16:51:03.693Z

I’m waiting for Rust to get values in generic types, so that it’s possible to implement it as a library.

OTOH if it was built into the language, it could be used in Option optimization (e.g. so that Option<u31> could fit in a 32 bit register).

system · 2019-03-25T08:23:23.504Z

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.