Bug: type string memory is not implicitly convertible to type string storage pointer

[Amxx]

Description

Consider the following code

    function setWithFallback(string memory value, string storage store) internal returns (ShortString) {
        if (bytes(value).length < 32) {
            return toShortString(value);
        } else {
            store = value; // ISSUE IS HERE
            return toShortString("");
        }
    }

    function getWithFallback(ShortString value, string storage store) internal returns (string memory) {
        if (length(value) > 0) {
            return toString(value);
        } else {
            return store;
        }
    }

store = value; refused to compile with error

TypeError: Type string memory is not implicitly convertible to expected type string storage pointer.

I would expect that to be valid, and to write the string in value to the storage slot corresponding to store

Environment

• Remix
• 0.8.17
• default config

Steps to Reproduce

Try to compile

library Test  {
    function writeToStorage(string memory value, string storage store) internal {
        store = value;
    }
}

[cameel]

It's more of a design choice than a bug, though whether it's a good one is up for discussion.

It works this way because both string storage store and string memory value are references and the assignment copies the reference, not the content. If we changed it, then it would be inconsistent with what happens when you assign between two string storage variables (it does not copy the content either, though in this case there is no error). The only case where an actual copy happens is when the target of the assignment is not a reference.

This is to some extent documented in Data location and assignment behaviour but it does not actually mention this case specifically. I also think the docs would be clearer if they properly distinguished between storage variables and references/pointers to them. The fact that they avoid making that distinction muddles the matter.

In any case, I don't think simply changing this behavior to make it copy is the solution here. We do have a solution to the general problem in mind, but that will require changes in the current copy/reference semantics. That's tracked in #2435 so I'm closing this issue. We'll likely end up introducing something like a copyof operator to make copies explicit.

[cameel]

By the way, I see something similar already reported in the distant past: #2458.