tserg

> i'm not sure it's such an easy fix. the original intent of this implementation (as far as i can tell) is to deal with progressive widening of abi types....

I think `slice` can be refactored since `length_literal` cannot be `None` if it must be a constant. https://github.com/vyperlang/vyper/blob/9cc56b618a54e6144829d6c056feb43e00c9c5fe/vyper/builtins/functions.py#L311-L329 Should I do it here or in a follow-up PR?

> Is this a duplicate of https://github.com/charles-cooper/vyper/pull/17 and/or https://github.com/charles-cooper/vyper/pull/18? Yes, it does look like they are addressing the same issue.

> interesting .. did > > https://github.com/vyperlang/vyper/blob/7b9d159b84c0e568378d53e753350e7f691c413a/tests/ast/nodes/test_hex.py#L9 > > not need to be changed? > also, is > > https://github.com/vyperlang/vyper/blob/7b9d159b84c0e568378d53e753350e7f691c413a/vyper/semantics/types/primitives.py#L339 > > now dead code? It's actually not dead code,...

This issue was introduced in 3abe588e05be6f6cbfac283739d797ef6c485756. Arguably, this appears that it should have been invalid syntax and therefore a bug with v0.3.7 rather than v0.3.8 - see this failing test...

I think it makes sense to support a direct return in this case since the concern with zeroing an existing value does not apply in a return statement, will wait...

An alternative and perhaps more scalable approach is to add a `_reads_environment` property to `BuiltinFunction`, which is set to `True` for `BlockHash()`. We can then define the set of builtin...

I have changed the approach to one that also fixes #3425.

> this is looking better. i'm still hesitant though, because i tried this myself and realized that the approach doesn't work for `raw_call` -- `raw_call` requires a call site in...

Thanks for opening this discussion! I agree with the points you made. At this moment, I am thinking of the following steps: - Pause development on Cairo 0.10 - Once...