Attempted explanation below.
Maybe a bit, conceptually, but there’s probably very little practical overlap.
What this is about
I’m going to demonstrate by example. I think that should be sufficient to show why this would be useful
Imagine you have two functions, calc.points that uses age, experience and skills parameters; and calc.threshold that uses a category parameter. (This is made up, but I’m sure we can imagine a scenario relatively close to this.
Now you want to report on whether the calculated points reaches that calculated threshold. We know how to do this in wikitext, usually easiest with a $let wrapper:
<$let
points={{{ [calc.points{!!age},{!!experience},{!!skills}] }}}
threshold={{{ [calc.threshold{!!category}] }}}
>
{{{ [<points>compare:number:gteq<threshold>then[passes]else[fails]] }}}
</$let>
But what if we wanted to do this in a filter? Although there are surely others, the most obvious case where we need to confine ourselves to a single filter is in a cascade. So let’s say we have a tiddler tagged $:/tags/ViewTemplateBodyFilter, that chooses our PassThresholdBodyTemplate in the case that the points for current tiddler passes the threshold. There’s no obvious way to do this.1 But with @CodaCoder’s suggestion, we could do this in a single filter like this:
title: $:/_/my/cascades/body/pass-threshold
list-before: $:/config/ViewTemplateBodyFilters/default
[calc.points{!!age},{!!experience},{!!skills}let[points]] <!--
^^^^^^^^^^^ -->
[calc.threshold{!!category}let[threshold]] <!--
^^^^^^^^^^^^^^ -->
[<points>compare:number:gteq<threshold>then[PassThresholdBodyTemplate]] <!--
^^^^^^^^ ^^^^^^^^^^^ -->
(I’m pretty sure we can’t actually nest comments in a filter like that, but the point should be clear.)
Here we assign variables inside the filter for use later in the filter. That’s the core of the proposal. It extends to allowing us to work with lists held by such variables, and one step further to intentionally limit ourselves to an initial slice of such a list. But the core is simply to allow in-filter variable assignment.
The discussion about this being a pass-through operator simply means that it doesn’t change the input context. Although it assigns a variable, it doesn’t interfere with the rest of the operation.
[[1]] [[2]] [[3]] [[4]] [[5]] +[multiply[2]let[evens]subtract[1]] <!--
^^^^^^^^^^, '+ current filter value: 1 3 5 7 9
'--but `evens` has: 2 4 6 8 10 -->
Comparison with Multi-Values Variables
Introducing Multi-valued Variables is a proposal @jeremyruston created, stemming out of his work with improving color handling, but with much broader implications. Thematically, it overlaps a lot with the OP; both deal with assignments of lists of values to a single variable and both offer in-filter ways of assigning such variables.
Syntactically, they are very different, though. I think the biggest difference from the discussion above is that MVV offers an assignment only as a filter-run prefix (syntactically, possibly a suffix), where as the OP here allows it almost anywhere you can have an operator.
1 Yes, I’m sure we can do this be creating still another function that takes age, experience, skills and category parameters, but this suggestion is about how to make things simpler for users, not how to make them possible.
“Let there be ‘Let’ on Earth, and let it begin Wiki” 