Data locations should be tied to types, not variable declarations.

[k06a]

Abstract

Solidity could allow to have storage references in memory structures or even memory arrays.

Motivation

Sometimes it is handy to have memory structure with some storage refs. Now we can use this trick, uncomfortable but works:

type DataPtr is uint256;

function get(DataPtr ptr) internal pure returns(Data storage data) {
    assembly {
        data.slot := ptr
    }
}

Specification

It would be convenient to have storage refs in memory struct by allowing following syntax:

struct Data {
    // ...
}

struct Object {
    Data storage data; // <- allow storage keyword here
    bytes32 context;
}

[ekpyron]

Yes, we plan on associating data locations with the type in the future, not with the variable declaration (which is currently the case). The same goes for calldata references in memory. Just the nonsensical combinations like memory references in storage should remain invalid. Not entirely sure we have an issue for that yet, though.

[k06a]

@ekpyron glad to hear that this kind of functionality was already planned

[ekpyron]

As for some more implementation details on this: for nested reference types, the outermost data location should become the implicit default data location for the inner types, so e.g. uint[][] memory x; would be short for uint[] memory [] memory x; (while after solving this issue we'll also have uint[] calldata [] memory x;). Similarly, for struct members the default, non-mentioned data location means inheriting the location from the struct itself. On the other hand variable declarations of variables of reference type will still have to specify the outermost data location explicitly. This way we should be able to pull this of in a non-breaking backwards compatible way.

Furthermore, in the longer term, this will be a prerequisite for a generics-ready type system, i.e. it's related to #13725 and #869