feat: add v2-compat mode to evaluation entry points - #364
Merged
Conversation
All evaluation entry points now accept a trailing options list; mode: :v2 expands to the v2 context-normalization flags (lowercase_keys: true, coerce_strings: true), with explicitly passed flags winning over the expansion. This lets consumers select v2 or v3 semantics per evaluation in the same VM - the mechanism engage uses to keep existing journeys on v2 behavior while new journeys adopt v3. The audit for this work corrected two stale claims in the release notes: the binary-literal recursion removal was reverted before rc.0 (6e8355a), and the documented v2 date-only DateTime = comparison was unreachable dead code because the parser collapses = and == into the same operator in both versions. Neither needs a compat flag; the compat test corpus pins both findings. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
smn
approved these changes
Jul 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
Give consumers a per-evaluation v2-compat mode so v2- and v3-semantics evaluations can run side by side in one VM.
What's in here
mode: :v2on all evaluation entry points —evaluate!/4,evaluate/4,evaluate_block!/4,evaluate_block/4,evaluate_as_string!/4,evaluate_as_boolean!/4,evaluate_template!/4now take a trailing options list.mode: :v2expands tolowercase_keys: true, coerce_strings: true; explicitly passed flags win over the expansion;mode: :v3/no mode keeps v3 defaults. Implementation is a singlenormalize_opts/1+ passing opts to theContext.new/2calls the entry points already make.test/expression/v2_compat_test.exs, 15 tests): proves v2 semantics under the mode (coercion, lowercasing, entry-point coverage, nested-template behavior, flag precedence) and pins the two audit findings below.develop..release/3-0-0:6e8355a) — literals still resolve as templates exactly as in v2, so no compat flag and no consumer migration is needed. The notes previously listed it as a shipped break.="fix" targeted unreachable code:OperatorHelpers.eq/1collapses=and==into:==at parse time in both v2 and v3, so=on DateTimes always full-compared. No behavior changed; no compat flag needed. (An earlier revision of this branch threaded alegacy_datetime_equalityflag throughEval— removed once the corpus proved the path dead.)The net v2→v3 runtime delta is exactly the
Context.new/2default flip, which is why the compat mode is only the two context flags.Verification
mix credo --strictandmix format --check-formattedcleanEval, the parser, or any evaluation path when opts are omitted — a baremix diff-level no-op for existing callers🤖 Generated with Claude Code