ethereum
Interfaces should not require data locations for dynamic types
The following should be a valid interface:
interface I {
function f(bytes) external returns (bytes);
}
It isn't because solc demands a data location on all dynamic types.
The data location of an argument or return value is an implementation concern that the caller does not care about.
Valid implementations of this interface can use either memory or calldata location internally, and that doesn't change the implementation relation.
I have a good understanding of Solidity and how the compiler handles data locations for dynamic types. This issue aligns well with my interest in improving smart contract design and language usability. I’ll start by reproducing the issue locally, reviewing relevant specs or discussions, and identifying whether a compiler behavior note or documentation update is more appropriate. I’m committed to clear communication and open to feedback throughout the process.
Very much agree @frangio. Every time I get forced by the compiler to declare data location in the interface, I become confused for a moment, because it doesn't make any sense. Then I start looking for a coin to flip it.
GM... i'm a blockchain developer and i'm efficient in solidity and cairo smart contract please can i be assigned the issue
Yes, I would not call it a bug, but this is definitely an unnecessary detail that we can and probably should remove, the same way we removed visibility from constructors. It actually came up a while ago in the context of external function pointers and we decided to remove locations from them in the next breaking release and consider interfaces as well: https://github.com/argotorg/solidity/issues/12778#issuecomment-1243882927
To be clear, we should remove locations from (non-library) external functions types in general, which then would extend also to function definitions in interfaces as well as unimplemented external functions in abstract contracts.
By the way, we should not just make it optional but just remove the location. That part is breaking though and will require a deprecation warning. We will need to decide whether it's a good idea to do that already in 0.9.0. We were planning to, but for now only with function pointers which is much less disruptive than doing that to interfaces.