Is `Type::StorageRef` the "right" way to indicate a value is in storage?

[smoelius]

My question concerns this code: https://github.com/hyperledger-solang/solang/blob/53202f876d83d97a55f84d99ca21af8e55fe609f/src/sema/ast.rs#L48-L49

In Solidity, an array, mapping, or struct is entirely in memory or entirely in storage.

One cannot, for example, have an in-memory array of in-storage arrays.

However, the above Type::StorageRef allows for such combinations.

Were any alternatives considered, e.g., a flag or enum to indicate where a value is stored?

---

EDIT: This issue seems related: https://github.com/hyperledger-solang/solang/issues/933

EDIT 2: This program provides an example of the problem: https://github.com/ethereum/solidity/blob/7e67811a82d55bb280f5a21e9b623e4c3d99fbca/test/libsolidity/semanticTests/events/event_indexed_string.sol

The cast on this line 7 performs a storage load and a cast of the resulting, in-memory value: https://github.com/hyperledger-solang/solang/blob/53202f876d83d97a55f84d99ca21af8e55fe609f/src/sema/expression/mod.rs#L179-L184 Thus, the pushes are performed to the in-memory value only, and storage is not modified.

[seanyoung]

You're right, a different way of describing this would be better. It had not occurred to me this is could be improved. I think Type will need to change support calldata and Solidity slices.

What do you propose?

[smoelius]

What do you propose?

The only alternative I can think of is to make Type a struct with a field indicating where its storage lies, e.g., memory, storage, or calldata. However, I have not investigated how difficult of a refactor that would be.