Struct instantiaton less efficient than tuple creation

[hiroshi-yamamoto-dublr]

Description

Given these two contracts (which from an ABI point of view, return exactly the same values):

contract A {
    function a() pure external returns (uint256 x, uint256 y) {
        return (0, 0);
    }
}

contract B {
    struct XY {
        uint256 x;
        uint256 y;
    }

    function b() pure external returns (XY memory xy) {
        return XY({x: 0, y: 0});
    }
}

contract A compiles to 0.122 kb
contract B compiles to 0.157 kb

This is a problem, because since tuples are not yet a first-class datatype in Solidity, you are forced to use structs in some situations where tuples should work, which causes the contract size to increase. For example, you can't declare a tuple type inside a struct. This doesn't work:

struct Data {
    uint256 a;
    (uint256 x, uint256 y) b;
}

You have to use instead:

struct Data {
    uint256 a;
    XY b;
}

Environment

• Compiler version: 0.8.17
• Target EVM version (as per compiler settings):
• Framework/IDE (e.g. Truffle or Remix): Hardhat
• EVM execution environment / backend / blockchain client:
• Operating system: Linux

[ekpyron]

Thank you for this issue! You're perfectly right here, ideally these functions would end up being optimized to the same code size and runtime costs. The main reason for the difference, is that tuples live on stack, whereas structs are (currently) always in memory - and temporary memory usage is generally not well optimized by the compiler just yet.
In the long run, this issue will be solved in two ways: by improving code generation in the presence of temporary memory use (#13722) and by moving to a more flexible type system, in which tuple types will be first-citizen types, as part of our general efforts of introducing generics to the language (#869).

In that sense, I'm closing this issue as a duplicate in the sense that it will be solved by already scheduled other issues, even though you will be a bit patient until we will have sufficient progress on those to ultimately achieve equal efficiency between the two cases you brought up.