Array slices for memory and storage arrays.

[ekpyron]

In 0.6.0 we implemented array slices for dynamic calldata arrays. We should also support them at least for dynamic memory arrays and maybe even for dynamic storage arrays. This will require more involved changes, though, since while calldata array slices and dynamic calldata arrays have the exact same stack layout and type conversion is a no-op, this won't be the case for memory and storage. We could also think about the case of static arrays combined with slicing.

[0xad1onchain]

Are there any updates on this issue?

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 90 days. It will be automatically closed in 7 days.

[github-actions[bot]]

Hi everyone! This issue has been automatically closed due to inactivity. If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen. However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.

[k06a]

Would be cool to have it for storage, can do with Solidity libs nowadays

[k06a]

What would you say about having new array access modifiers?

• storage slice
• memory slice

Which would have 2 variables on stack, similar to calldata offset and length?

Where storage and memory could have auto-cast to sliced versions.

[cameel]

I was thinking about how we can do this and I don't see a realistic way to have storage and memory slices that are fully interoperable with arrays. By this I mean being able to take a memory slice and e.g. pass it into a function that expects an array. As mentioned above, this is possible with calldata arrays, because they share the layout with slices - since the array is read-only, we do not have to care about the length field and can simply store its value on the stack.

With memory slices this kind of interoperability is technically achievable, but it would be quite messy and costly. We would have to change the current stack layout of memory arrays to make them use two slots (to track the length field and data area separately). This would increase the cost of memory arrays in general, even when you don't use slices at all. We would also have to allocate a length slot in memory for every slice.

For storage and transient storage even this is not possible - we cannot freely allocate new slots without potentially stepping on user's variables.

I think that due to this, memory/storage slices won't ever be freely interchange able with array references in the language. What we can do instead is to provide an explicit slice type, so that you can opt in. Array references would be implicitly convertible to such a type, so functions taking it would accept both arrays and slices. It would be a bit cumbersome unfortunately - having to decide between one or the other or implement things twice - but it would at least not add hidden cost to every use of a array in the language.

Core Solidity will offer generics, which should make defining functions compatible with both possible and a non-issue in the long-term.