[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

Add conformance cases for WIP3 expressions in for collections, limit and numeric offset.

Problem

The loop parser still rejects expression forms that WIP3 already accepts in assign. Extending it needs both new-behavior cases and fixed expectations for existing successful loops.

Solution

specs/liquid_ruby/for_shared_expressions.yml covers grouped and ungrouped expressions, modifier boundaries, loop metadata, ranges, continuation, reversed iteration and empty loops. Existing-output expectations come from the pinned WIP3 baseline; the new results are the human-approved feature examples.

Paired implementation: Shopify/liquid#2133. These cases target that WIP3 stack.

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 #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.