Safe value types

[romanagureev]

Simple Summary

Make it easy to use numeric values that are allowed to be only within given ranges (and optionally only certain discrete values).

Motivation

When doing math, values may converge and/or have needed properties only for some range (e.g. 10**12 .. 10**36). For example, the Balancer incident wouldn’t be feasible if one restricted Wei swaps. Currently this can be achieved through additional asserts on values, though it makes it hard to follow all inputs/outputs and makes the code clumsy. Adding defined ranges/conditions for values may improve explicitness.

Specification

Basic usage is defining acceptable ranges for values, e.g. 10**12 .. 10**36 for amounts and 10**5 .. 10**10 for fees, with similar ranges for other parameters. Amount values might also need to accept 0. Open question: how to deal with values like 10**18 + 1—in some cases it might be helpful to fully ignore wei values (if it doesn’t break EIP requirements).

Illustrative syntax (suggested by AI):

amount: uint256[10**12:10**36]
fee: uint256[10**5:10**10]
amount18: uint256[10**12:10**36, step=10**10]

Backwards Compatibility

Compatible.

Dependencies

References

• Balancer incident: https://rekt.news/balancer-rekt2
• ERC4626 Virtual shares could be also solved by limiting deposit values as in YB

Copyright

[Sporarum]

I'm all for it !
(I worked on something even more general for my master thesis: types with arbitrary predicates)

However we have to be conscious that this can easily lead to an explosion in language features.
Because once you add range types, you want want path typing:

if x > 10**12:
   # I really don't want to have to write this out:
    x = convert(x, uint256 in 10**12..INF>) 
    ...

And you might want integer type parameters:

def safe_add<min, max>(x: uint256 in min..max, y: uint256 in min..max): uint256 in (2*min)..(2*max)

And so on

Again, not saying we shouldn't do it, it's very cool and useful !
But we have to be ready to have a to anticipate these requests to make sure we're ready for them, and/or modify our proposal accordingly

[Sporarum]

For the syntax, I'd much prefer something like:

amount: Range[uint256, 10**12, 10**36]
amount18: Range[uint256, 10**12, 10**36, step=10**10]

As otherwise there might be confusion between:

a: uint256[10] # fixed-size list
b: uint256[10:12] # integer between 10 and 12

Ideally we'd find a way to express whether the bounds are inclusive or not, maybe something like:

b: uint256 in 10<=..<12 # integer between 10 (inclusive) and 12 (exclusive)