[charlespwd]

Warning

Research / WIP
Experimental output from liquid-factory, shared for design and code feedback. This is a research draft for the WIP3 stack, not a merge-ready language change.

In this PR

Let for use WIP3 expressions directly for its collection, limit and numeric offset, with or without parentheses.

Problem

These expressions already work in assign. Using one in a loop currently requires a temporary assignment first.

Solution

Use Parser#expression for the new forms. Previously accepted forms keep their original interpretation, loop names and continuation keys. That compatibility path matters for existing lookup and range quirks that render differently through the shared AST.

Paired specs: Shopify/liquid-spec#168, adding the approved cases in specs/liquid_ruby/for_shared_expressions.yml. This feature is based on WIP3, not main.

Feature boundary

Outcome

for collections, limit and offset accept the existing WIP3 expression forms, so a loop can use a grouped or boolean expression without first assigning it to a temporary variable.

Scope

• Collection, limit and numeric offset values use expressions already supported by the WIP3 shared grammar: variable and property/index lookups, literals, ranges, groups, and logical, equality and comparison expressions where their value is meaningful in that position.
• Expressions keep WIP3's existing evaluation semantics. For example, or and and return operands, as they already do outside for.
• The loop variable remains an identifier. The existing limit, offset, reversed and offset: continue syntax keeps its meaning. An expression-valued collection must not change the name/metadata or continuation behavior of loops that already succeed.
• case/when alternatives keep their existing or meaning.

Acceptance boundary

• The paired specs/liquid_ruby/for_shared_expressions.yml states the approved new results and byte-identical preservation cases.
• Grouped and ungrouped WIP3 boolean expressions can supply a collection, limit and offset; the cases use existing operand-return behavior and positive integer operands without adding numeric coercion rules. A combined case preserves the collection/limit/offset/reversed boundaries.
• Existing successful loop results and metadata remain unchanged, including the loop name, index and length; range iteration; limit and offset; offset: continue; reversed order; and empty/else handling.
• Existing when alternatives remain unchanged. The compatibility case protects their existing meaning while the for grammar is broadened.

Non-goals

• Array or hash literals, arithmetic operators, and parenthesized filter pipelines. Those have separate feature runs and no such syntax is proposed here.
• New boolean operand or numeric coercion behavior, negative limits, new range behavior, or changes to collection iteration.
• Changes to loop-variable/name syntax, offset: continue, reversed, or case/when alternatives.

Dependencies

• Shopify/liquid PR WIP3 #2021 (WIP3), branch cp-boolean-expressions: the existing shared expression grammar and its evaluation behavior. Present at the pinned Liquid base ecf53f7af7749237b639579792e4c681cbd4a480; this run's Liquid PR targets that branch, not main.
• liquid-spec: no separate feature dependency; the paired spec run is based on aac52d5c55627375ff4e6984d1ce53e53e61afed.

These cases are examples, not proof that every possible template keeps its output.