feat: add min and max value builtins

[tserg]

What I did

Fix #1923.

How I did it

Add min_value and max_value builtin functions.

How to verify it

See tests.

Commit message

feat: add min_value and max_value builtins

Add min_value and max_value builtins for bounds of numeric types.
Remove builtin constants MAX_INT128, MIN_INT128, MIN_DECIMAL,
MAX_DECIMAL and MAX_UINT256.

Description for the changelog

Add min_value and max_value builtin functions.

Cute Animal Picture

[codecov-commenter]

Codecov Report

Merging #2935 (83f87ed) into master (4b3b636) will decrease coverage by 1.53%.
The diff coverage is 97.05%.

@@            Coverage Diff             @@
##           master    #2935      +/-   ##
==========================================
- Coverage   88.10%   86.56%   -1.54%     
==========================================
  Files          97       97              
  Lines       10877    10923      +46     
  Branches     2574     2522      -52     
==========================================
- Hits         9583     9456     -127     
- Misses        838      995     +157     
- Partials      456      472      +16     

Impacted Files	Coverage Δ
vyper/semantics/namespace.py	97.29% <ø> (ø)
vyper/builtin_functions/functions.py	86.61% <96.55%> (-3.64%)	⬇️
vyper/ast/folding.py	92.62% <100.00%> (+1.02%)	⬆️
vyper/builtin_functions/convert.py	67.02% <0.00%> (-23.58%)	⬇️
vyper/codegen/arithmetic.py	54.87% <0.00%> (-20.88%)	⬇️
vyper/semantics/types/value/numeric.py	79.31% <0.00%> (-5.75%)	⬇️
vyper/ast/validation.py	75.00% <0.00%> (-4.17%)	⬇️
vyper/utils.py	80.86% <0.00%> (-3.83%)	⬇️
vyper/ir/s_expressions.py	91.17% <0.00%> (-2.95%)	⬇️
... and 7 more

Help us with your feedback. Take ten seconds to tell us how you rate us.

[charles-cooper]

looks nice! i might rename def _eval_fn() to def _eval().

also i think we want to be sure not to actually remove the old constants from the language. We can deprecate them but we should keep them in for a few releases to avoid breaking user code.

[charles-cooper]

i mean we might as well get rid of ZERO_ADDRESS and EMPTY_BYTES32 while we are at it

[tserg]

We can support min_value(bytesN) as well since Vyper now has all bytesN types.

[charles-cooper]

well that's just empty(bytesN). actually i think for types T where min_value(T) == empty(T), we should block min_value(T) and suggest empty(T) instead (on the principle that there should be one obvious way to do things).

[tserg]

oh right, so empty() is already sufficient for ZERO_ADDRESS and EMPTY_BYTESN.

in that case, the only types where min_value(T) == empty(T) are unsigned integers only though. hence, I think supporting min_value for signed integers but not unsigned integers would be more confusing than having min_value and empty for unsigned integers.

[tserg]

To discuss replacing min_value and max_value with lower_bound and upper_bound / typemin and typemax.

[tserg]

Notes from meeting on 25 July: proceed with min_value and max_value

[charles-cooper]

meeting notes:
use min_value and max_value (and include min_value for unsigned integers)

[tserg]

Do we need to support decimal?

[charles-cooper]

Do we need to support decimal?

yes, that would be good!

[charles-cooper]

looking quite good. couple small things

[charles-cooper]

it's nice to use this _eval function. dispatching to min/max is a bit magical though. for instance, if the signature of int_bounds ever changes, you would expect this function to break actually - and it wouldn't!

i would say this would be slightly clearer with two functions, _eval_decimal and _eval_int. each takes the input type and returns a value. so this block would look more like

        if isinstance(input_type, IntegerAbstractType):
            val = self._eval_int(input_type)

and similar for the decimal case.