Open Philogy opened 5 days ago
i've been thinking about this for awhile and it would be good to replace the slice builtin. the nice thing is it gives us a way to fix the current API ugliness of slice()
(iirc, it is very frustrating that it reverts when the requested length is larger than the length of the provided bytestring, this usually comes up during bytestring building routines)
ah, dup of https://github.com/vyperlang/vyper/issues/3562 (but i left the specification as a stub)
Simple Summary
Instead of typing out
slice(my_sliceable_var, start, length)
I'd like to be able to use slice syntax i.e.my_sliceable_var[start:end]
. It should have the same behavior and be bounds-checked.An alternative would be to implement Rust's slicing syntax
[start..end]
and[start..=end]
. What's nice about Rust's approach is that gives syntatic sugar to differentiate between exclusive and inclusive ranges which can be nice. Reused it could serve as syntax sugar forrange
in the future.Motivation
The
slice
builtin leads to some relatively verbose syntax. Square brackets are widely recognized across several languages to represent slicing and will be familiar to most people. Both Solidity & Python support the slicing operator in the form of[start:end]
. Rust is quite popular too so[start..end]
will be familiar to a lot of devs too.Specification
TBD.
Backwards Compatibility
Backwards compatible as this wasn't valid syntax before.
Dependencies
None afaik.
References
-
Copyright
Copyright and related rights waived via CC0