I’d propose that the language permit functions to both accept and return arrays of fixed size via parameters characterized as dynamic.
At present, for example if the function signature is function getKeys() public pure returns(string[] memory)
A return value of return ["key1", "key2"];
won’t compile due a type error (string[2] not compatible with string[]), which is both surprising and extremely inconvenient making it very difficult for example to use library functions which will work on arrays of varying sizes.
I would propose that either function parameters or return values specified as someType[] memory accept or return values of either fixed or dynamic type.
If it is important (for reasons I don’t completely understand) to discriminate between dynamic arrays and fixed arrays of arbitrary size, maybe the syntax could be that returns(string[] memory) could be limited to functions which return dynamic arrays (as current) , and returns(string[?] memory) only returns fixed arrays but of any arbitrary size.
Yes, it would be useful. The obstacle is technical: dynamically- and statically-sized arrays have different internal layouts. Dynamic ones have a length field at the beginning while for static ones the length is implied. It would actually be possible to treat a dynamically-sized array as a static one by ignoring the length field but not the other way around.
One workaround might be to reserve extra space before static arrays at the spot where the length would be. This would make statically-sized arrays slightly more expensive in terms of gas though.
Another would be to perform a conversion by allocating a completely new array but that would be much more expensive. This solution solution might be more acceptable for parameters and returns of external functions where the data must be copied in the process of encoding or decoding it anyway.
Overall it’s mostly about how to do this in a gas-efficient manner and avoid copies where they would be unexpected. There are already feature requests for this, but thanks for bringing up this topic on the forum anyway because it does need more discussion and brainstorming.