[IDEA] Filter operator to save its input into a variable accessible in later filter steps

[rmunn]

Is your feature request related to a problem? Please describe. While coming up with examples for #6892 (which suggests a new interleave filter operator), I had the idea that one might want to interleave the results of several previous filter operations. For example, interleave[enlist{Days of the Week!!short}uppercase[]],[range[7]] to get MON 1 TUE 2 WED 3 etc.

The way you'd do this now is to use $let to assign variables, then use them later. E.g.,

<$let days={{{ [enlist{Days of the Week!!short}uppercase[]] }}} nums={{{ [range[7]] }}}>
  <$list filter="[interleave<days>,<nums>]" />
</$let>

This works in many situations, but sometimes there are filter expressions that would be better written as a single unit. For those situations, it might be nice to have a setvariable operator that would work like this:

<$list filter="""
[enlist{Days of the Week!!short}uppercase[]setvariable[days]]
[range[7]setvariable[nums]]
[interleave<days>,<nums>]
""" />

The result of this would be exactly the same as the previous example: MON 1 TUE 2 WED 3 and so on.

Describe the solution you'd like The setvariable operator described above, with a note in the documentation that the variables set this way are only available during the filter expression, and not available outside it. (The $let widget is perfectly adequate for variables that need to be used in more places than a single filter expression).

Describe alternatives you've considered The way it works right now is good enough, but sometimes I find it clearer to write things as a single filter expression than to break the expression up into multiple parts.

[Jermolene]

Thank you @rmunn I've also thought along the same lines.

A concern is that the resulting filters are pretty complex, introducing a new type of internal dependency which requires careful reading to understand.

Meanwhile, the custom functions in #6666 allow us to break complex filters into subfilters that take parameters, which also allows the same result to be used more than once. Making meaningful names for custom functions also helps enormously with readability.

I think we should explore #6666 a little more, but I'd definitely like bear this idea in mind.