Each() function

[matthew-dean]

The each() function relies on the root function functionality of the recent @plugin PR, so those files show as part of this PR.

This addresses the thread in: #2270 and probably a lot of other related looping / lambda issues. There were a lot of syntax suggestions in #2270, so feedback welcome.

Basically, each has a pretty simple signature:

each([list], [variableNames], [ruleset])

Variable names are optional, but necessary if you want to do fancy things with nested eaches (like access the parent item or index), just because of the way variable scope works in Less.

Just like the @arguments variable, the each function assigns a special var for the list item and index, named by default @item and @index.

So, it looks like this:

// less
.vector-math {
  each(1 2 3 4, {
    padding+_: (@item * 10px);
  });
}
// css
.vector-math {
  padding: 10px 20px 30px 40px;
}

Here's an advanced each() example added to tests:

// less
#list-details {
  each(10px 15px, 20px 25px; { 
    @alpha: a b c d;
    @i: (@index - 1);

    each(@item; key, val; {
      @a: extract(@alpha, (@i * 2 + @key));
      nest-@{a}-@{index}: @val @key;
    });
  });
}
// css
#list-details { 
  nest-a-1: 10px 1;
  nest-b-1: 15px 2;
  nest-c-2: 20px 1;
  nest-d-2: 25px 2;
}

One minor note: this PR also separates list functions into their own function file.

[seven-phases-max]

@matthew-dean By the way. If we allow all these "mixin-like" arguments for functions, will there be any difference between mixin.arguments() and function.arguments() beside the "named arguments" thing? Obviously I'm just considering if this code can be reused somehow. I understand that because of the "named args" they need to return different structures, but are there any other differences?

[matthew-dean]

There were various bits I modified from mixin args to functions args. One is that there are legacy IE "function-like" calls that need to be parsed but that mixins don't parse. (Which I'm not sure are still needed, but it's possible that legacy CSS code continues to persist in currently-used mixins.) It's possible that may be the only real variation, at least for calls. The code for mixin args is re-used between both mixin calls and mixin definitions, so it's possible we could collapse args for "function calls" and "mixin calls", and break out mixin definitions? Or maybe could just collapse all 3 with appropriate if statements.

[seven-phases-max]

Thanks... Yes, it seems to need more investigations on possible unifications.
I was just about to experiment with some @var(args...); stuff, and realized that having three distinct functions to handle pretty much the same syntax would be somewhat an overkill. Additionally I recall that for #1857, I was also thinking of allowing @arg... stuff for functions too, but quickly bailed out because of all these differences :(

[matthew-dean]

Closing this PR.