The listing below shows those operators where one or more arguments are conditional. This means the argument , apart for the case of if(), acts as a further filter to a scoping argument, as items evaluating false are dropped from the the source listing (in the case of dot-operators) or scope-derived list of item processed by the action.
Why the need for such a two-part approach of scope+condition? Early in the life of the app, the only scoping values allowed were designators which at that time did not include the ad hoc find(query) designator. Thus conditional tests allow fine tuning of a designator's scope. In many cases a find(query) used as the scope argument may obviate the need to use a conditional qualifier, but often the two part approach can be easier to write; either way the outcome can be the same.
Some operators support deeper evaluation than others—think of that in terms of how many nested levels of offset address arguments are included, or the number of implicit nested levels of evaluation. The variation might be from an explicit literal string for $Name or $Path, through data stored in an attribute, data stored in an attribute is a different note, to complex action code expressions. This aspect of operators is not well documented. The more complex the intended argument value, the better it is to do a small rest file first to ensure the argument is evaluated correctly before using the same in a large document.
List of such operators:
- any(scope, condition)
- avg_if(scope, condition, expressionStr)
- collect_if(scope, condition, expressionStr)
- count_if(scope, condition)
- every(scope, condition)
- if(condition){actions}[else{actions}]
- List/Set.collect_if(loopVar, condition, expressionStr)
- List/Set.count_if(loopVar, condition)
- List/Set.sum_if(loopVar, condition[, expressionStr])
- String.eachLine(loopVar[:condition]){actions}
- sum_if(scope, condition, expressionStr)
- while(condition){}