array comparison is not allowed

[charles-cooper]

Version Information

• vyper Version (output of vyper --version): df54e00

What's your issue about?

arrays are syntactically allowed to compare operators, but only the first element gets compared.

here's an example:

@external
def foo() -> bool:
    x: int128[3] = [1,2,3]
    y: int128[3] = [2,3,4]
    t: bool = x ==  y
    return t

this generates the following IR

                    /* x: int128[3] = [1,2,3] */ 
                    [seq,
                      [mstore, 224, 1 <1>],
                      [mstore, 256, 2 <2>],
                      [mstore, 288, 3 <3>]],
                    /* y: int128[3] = [2,3,4] */ 
                    [seq,
                      [mstore, 320, 2 <2>],
                      [mstore, 352, 3 <3>],
                      [mstore, 384, 4 <4>]],
                    /* t: bool = x ==  y */ 
                    [mstore,
                      416,
                      /* x ==  y */ [eq, [mload, 224 <x>], [mload, 320 <y>]]],
                    # Line 10
                    /* return t */ 

How can it be fixed?

Probably just block the behavior at the semantic level

[fubuloubu]

a full implementation of this would have to be a mutual iteration check, (made easier with zip?)

[fubuloubu]

e.g. via ast-substitution, do:

t: bool = True
for a, b in zip(x, y):
    t = t and a == b

---

edit: maybe a case for reduce?

t: bool = x == y  # = reduce(lambda t, (a, b): t and a == b, zip(x, y), True)

[charles-cooper]

I think we would use the same strategy as we use for bytes, i.e. hash both inputs and compare the hashes. I'm not sure we really want to get into e.g. array1 < array2

[fubuloubu]

I think we would use the same strategy as we use for bytes, i.e. hash both inputs and compare the hashes.

Depends on context, but this might work nicely. Also as an optimization, just check len(a) == len(b) first

I'm not sure we really want to get into e.g. array1 < array2

Not even sure what this would mean lol

[charles-cooper]

this behavior was blocked in #2633, so I'm demoting this issue from bug to enhancement