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

[smoelius]

My question concerns this code:

solang/src/sema/ast.rs

Lines 48 to 49 in 53202f8

	/// Reference to storage, first bool is true for immutables
	StorageRef(bool, Box<Type>),

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: #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:

solang/src/sema/expression/mod.rs

Lines 179 to 184 in 53202f8

	return Expression::StorageLoad {
	loc: *loc,
	ty: *r,
	expr: Box::new(self.clone()),
	}
	.cast(loc, to, implicit, ns, diagnostics);

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.