Should tuple unpacking from lists be supported?

[plajjan]

We support unpacking tuples, like

def fjong() -> (int, int):
    return 1, 2

actor main(env):
    a, b = fjong()
    env.exit(0)

but if instead a list is returned, we don't support unpacking entries from the list. This is slightly annoying as it's a fairly common pattern to directly unpack parts from split:

actor main(env):
    a, b = "a:b".split(":", 1)
    env.exit(0)

I guess it could just fail with IndexError if it doesn't return enough parts, no? or is that a big no no?

[nordlander]

A core aspect of tuples is that they all have a statically known arity, that either tells that it contains exactly that number of elements (with known types), or (optionally) at least that number of known elements. Type-checking tuples amounts to checking that these arities and the corresponding element types are respected at all times. In that sense tuples are just mirroring the rules that apply to functions regarding arities and parameter types.

So the problem with letting split return a tuple is that the arity of that tuple would inherently depend on the contents of the string to split. As an example, consider

def fun(x: str):
    a, b = x.split(":", 1)

The type of x doesn't reveal whether it contains any : characters at all, so we would have to resort to dynamic arity-checking when matching the split result against the pair a, b -- which kind of goes against the fundamental idea of the tuple type.

However, we do actually support something very similar in the form of list patterns, which makes the following example fully valid:

def fun(x: str):
    [a, b] = x.split(":", 1)

Not much of a syntactic difference, and since the list type doesn't come with any promise regarding a list's length it is much more appropriate to raise an exception at run-time if parameter x above happens to contain no : characters. In fact, the semantically identical example

def fun(x: str):
    temp = x.split(":", 1)
    a = temp[0]
    b = temp[1]

is what the compiler translates (or should translate) the list pattern into.

Unfortunately, when verifying this with the compiler I discovered that the witness translation for list patterns is actually flawed, leading to a crash later on in the deactorizer pass. Not difficult to fix, though, and I'm opening an issue about this right away.