Array literals should be convertible to both dynamically-sized and statically-sized arrays

[chriseth]

We could implement this using a new type for array literals and the codegen could store the elements in memory while reserving a memory slot for the length (and just not use it for the static case).

[chriseth]

This could also solve the weird type deduction for array literals: Currently, [1,2,3] is a uint8[3] and uint[3] t = [1,2,3]; is invalid. If we do not assign a "proper" array type to the array literal expression right away, but rather keep it more similar to how tuple types currently work, this should be much easier to use.

[ekpyron]

We don't need to (nor want to?) allow naming these types, do we?
Then it would only be usable in contexts in which we could deduce whether it will end up dynamically or statically sized, so code generation would already know and be able to handle the cases separately without reserving slots and the like.

[chriseth]

That is true, but we would need to pass that through the type checker, which is not always easy to do.

[ekpyron]

At one point or another, the type checker needs to check if the array literal expression is convertible to the type it'll end up in and can just annotate that then, can't it?
It'd even consistently work for plain [1,2,3]; or even for [f(), g(), h()];, which wouldn't be annotated by any concrete array type, meaning that nothing needs to be stored anywhere and the subexpressions can just be evaluated and the results discarded in codegen...

[chriseth]

((([1,2,3]))) - it can be arbitrarily nested.

[chriseth]

Oh and there also is [[1,2], [4,5]]

[ekpyron]

Ok, maybe it's nontrivial :-). But should still be possible, shouldn't it :-)...?

And those nested single-component tuples are quite annoying everywhere, maybe we should just get rid of that once and for all :-D. But that's a different topic.

[chriseth]

Implementation note:
Should introduce a new type similar to TupleType (maybe that one can be re-used with an additional boolean) which has one separate type per component. In TypeChecker::visit(TupleExpression, most of the checks can be removed. The type of the expression should be the new inline array type, where each component is just the type of the component.

Convertibility of this new type should be to statically-sized and dynamically-sized array type where each component type is convertible and the size matches.

Code generation should store each component in memory (and probably already convert to the target type).

Since we already need to convert to the target type anyway, we can maybe use @ekpyron 's idea of forwarding the target conversion type.

So it might be that this gets a bit more complicated.

[chriseth]

Forwarding the target conversion type will be very tricky, since there are too many situations in which this can happen, in my opinion.

In summary, I think we can only achieve the following without considerable effort:

We add an additional flag to ArrayType that is valid for statically-sized arrays in memory and tells that it is fine to convert this array into a dynamically-sized array. The flag is only set for array types deduced from TupleExpressions that are inline arrays for now.

Such array types are convertible to other such array types if the size matches (this is needed for two-dimensional inline arrays). They are convertible to statically-sized array types of the same size or dynamically-sized array types.

In code generation, they are handled as dynamically-sized memory arrays.

When converted to statically-sized memory arrays, we just add 0x20 to the pointer, while conversion to dynamically-sized memory arrays is a no-op.

The .length member and index access has to be done accordingly.

Another option to implement this is to make mobileType() to be the dynamically-sized memory array. I think this could require less implementation effort, but I'm not sure.

The difference between the first (A) and the second (B) way to implement it is that:

In (A), the expression [[1, 2], [4, 5]] can be converted to uint8[2][2], while it can only be converted to uint[][2] in (B).
On the other hand, [[1, 2], [3]] is valid in (B), while it is invalid in (A).

[ekpyron]

I still don't see the problem in determining up front whether the array is static or dynamic.

We do type checking - if it's possible to type-check these things, we have to know which type it has to end up in in order to validate that it's convertible - so we do know the type statically up front anyways in that sense. The worst thing that can happen is having to store it in an additional annotation and/or pass it down through a few nesting levels just as we do for the one-element-tuple-things at a lot of places anyways...

But I may be missing something and if I'm wrong and that really is problematic to do, the reserved length slot is ok-ish I guess.

[chriseth]

We can do it, yes, but I fear it might cause more problems than it solves, not only in using f for uint[]; / [1,2,3].f().

[ekpyron]

I don't see how the implementation detail for code generation affects stuff likeusing.

[chriseth]

Ah then I misunderstood you, I thought you wanted to use that for type checking as well, like determining the type of [[1,2], [4,5,6]]