Destructuring assignment frequently becomes useless when paired with other features

[hal-ullr]

Just an example:

{:a, :b} = {a: "Hello", b: "World"} if true
print a, b

Results in nil nil. Obviously the expressiveness of MoonScript allows this to be easily rewritten in a more effective way, but the behavior is difficult to debug without examination of the product.

[leafo]

This is the same as writing

if true
  {:a, :b} = {a: "Hello", b: "World"}

Scoping in lua says that any variables introduced in a block are only available in that and nested blocks below. So when the if statement is left they are longer there.

Because assigning and losing the variables isn't useful, I decided to break the rules. I added support for hoisting variable local calls for if statement decorated lines. So this would make a,b available.

a,b = 1,2 if true

I didn't add it for destructing though, so it's a bug.

Could you explain more about how you think destructing assignment becomes useless?

[hal-ullr]

Here's an example from one of my own scripts, with a constant spliced in:

{days, hours, mins, secs} = [tonumber a for a in *{
    string.match "1 2 3 4", "(.+)%s(.+)%s(.+)%s(.+)"
}]

print days, hours, mins, secs

This would seem like an example in which I wouldn't have to worry about a hidden block, as the for loop is in a list comprehension. However, the product still isolates the list in a block so it does nothing and I end up with nil nil nil nil again.

However, if I split it up into separate lines:

a = [tonumber a for a in *{
    string.match "1 2 3 4", "(.+)%s(.+)%s(.+)%s(.+)"
}]

{days, hours, mins, secs} = a

print days, hours, mins, secs

It works just fine.

[leafo]

Ah, interesting. That's definitely a bug. Got any others?

[hal-ullr]

No, not really. Probably any bit of syntax that requires its own block will have a leading destructuring assessment drop its values in a soon to be terminated block.

[leafo]

closing this in favor of #391 as it more accurately describes the specific issue