Predicate-passing in Handlebars filter helpers (ad-hoc filtering)

[gennaroprota]

Discussed in the #1199 review (Alan). Handlebars' filter helpers (filter_by, reject_by, select, any_of_by) take a key name, not a predicate: they test whether a member is truthy at a given key. Any filter with a non-trivial condition therefore has to be expressed as a Boolean key on the element, which pushes presentation logic into the data model.

Scope note: the bulk of that pressure (the is* derived-value family) is better solved by computed properties via reflection, tracked in #1215. Computed properties are compiled C++ calls and belong on hot paths and in the default templates. This issue covers the remaining case: genuinely ad-hoc, author-time filters where defining a named computed property would be overkill and the interpreted cost is acceptable.

Goal

Let filter_by / reject_by (and select / any_of_by) accept an arbitrary subexpression as a predicate, not just a key path. Roughly:

(reject_by tranche.functions (eq this.template.specializationKind "Explicit"))

The predicate runs with this bound to each element. The current key-name shape stays valid as a shorthand for "truthy at this key."

Open questions

• Composition with the existing key-name shape: overload by arity (a callable second argument is a predicate, a string is a key), or a sibling helper with the key-name forms as sugar.
• Lazy evaluation: the lazy-DOM work (Build DOM objects lazily directly from reflection descriptors #1211) changes the cost model, so predicate-passing should compose with it rather than against it.
• Symmetry across filter_by / reject_by / select / any_of_by: one design pass over all of them rather than per-helper.
• Cross-corpus lookups inside predicates: some filters need to consult other symbols. Where that condition is stable and reusable, a computed property (Computed properties via reflection (MRDOCS_DESCRIBE_COMPUTED_PROPERTIES) #1215) is the better home; predicate-passing only needs a corpus-lookup primitive for the ad-hoc remainder.

Scope

Design and implementation over the filter_by / reject_by / select / any_of_by surface in src/lib/Support/Handlebars.cpp. This is the interpreted path, explicitly not for default templates; for those, prefer computed properties (#1215).

[alandefreitas]

On the open questions

Composition with the existing key-name shape.

We just need the version without the "_by" suffix.

Lazy evaluation. Today the helpers materialize the input array eagerly.

That's OK. We can do all lazy things in the future unless it's cheap to do it now. There are more important things to make lazy right now.

Symmetry with select and any_of_by.

Similar answers

Cross-corpus lookups inside predicates.

This one is independent from the issue

(reject tranche.functions (eq this.template.specializationKind "Explicit"))

The final syntax probably won't look like this though. Because this already have a meaning, which is

(reject tranche.functions result-of-the-expression)

The function need to have access to the internal function (not to the result of an expression that uses it), so it's probably going to be something like:

(reject tranche.functions helper-function extra-param1 extra-param2 ...)