Don't skip nil result in loop expression, breaking change

[leafo]

Currently, if you assign a loop to something, or treat it as an expression the result of each iteration is accumulated into an array.

This is very similar to comprehensions, but if the result of an iteration is nil then it is not added to the array.

This makes something like this possible:

my_numbers = {1,2,3,4,5,6}
odds = for x in *my_numbers
  if x % 2 == 1 then x

The obvious downside is that these two things are not the same thing:

out = for x in y
  x

out = [x for x in y]

Since making this decision I've added the continue statement. It works with loop expressions, so the nil check can be done explicitly:

odds = for x in *my_numbers
  continue unless x % 2 == 1
  x

I think it's better to be explicit in cases like this. Therefore I plan to remove this nil check in the loop format.

This is a backwards incompatible change. I've been going through some of my old code and it's kind of annoying finding instances of loops that need to be updated. That's why I'd like some feedback. Maybe this change is not worth it.

[fillest]

I personally don't have too much loops to update yet :] but i think it's worth it anyway

[ariabuckles]

I've used/exploited the fact that nils don't get added in for loops before, and I approve this change. Being able to do either using continue is better than the current inability to add nils, in my opinion.

One thing to consider might be whether

list2 = for x in *list1
if x > 5 then x

ought to be interpreted as

list2 = for x in *list1
if x > 5 then x else continue

or

list2 = for x in *list1
if x > 5 then x else nil

I think it's very reasonable that "else nil" should add the nils to the array. What's less clear, to me, is whether no else clause ought to add a nil to the list (are there any other situations where you can get an implicit nil result? I'm not recalling any off the top of my head, but it's late.)

I'll probably have to spend a bit of time going through old loops to catch these, but I think this change is worth it. One thing that Lua got right, in my opinion, is the acceptance of making breaking changes. I think if you split languages into categories of "wants backwards compatibility" and "wants to improve the language at the expense of backcompat", you'll find much nicer languages in the second list. Also, Moonscript is new, don't be afraid to make breaking changes if they're for the better. I want to see this language grow.

[leafo]

done many years ago and I never looked back!

[ariabuckles]

👍