Class ReplacesTargetOnCompletion

java.lang.Object
org.ek9lang.compiler.support.streams.ReplacesTargetOnCompletion
All Implemented Interfaces:
BiPredicate<Ek9Types, StreamTermination>
public final class ReplacesTargetOnCompletion extends Object implements BiPredicate<Ek9Types, StreamTermination>
True when a stream statement's > REPLACES its target when the pipeline completes (Steve, 2026-10-21: "> 'clobbers' and >> 'appends'", the Unix shell meaning; made ALL-OR-NOTHING the same day, and extended to a PriorityQueue and a JSON: "> always means REPLACE"; to a scalar 2026-10-26; and finally to EVERY target, no type list, 2026-10-27: "let's make > consistent"): the termination is > (never >>) and the target is anything but an output channel (IsOutputChannel). THE one decision (D77) - IR generation asks it once and carries the answer as plain IR: the pipeline folds into a FRESH value and, only when the pipeline completes normally, target :=: fresh runs ONCE. So every source reads what the target held (in every shape: single, multi-source, after a sort or async), a pipeline that throws leaves the target UNTOUCHED, an alias sees the result, and an empty source leaves a collection empty and set (and a fold unset). A back end never re-derives it. What is NOT replaced: an output channel (a Stdout, a StringOutput, a file, a UDP or TCP connection - it gets OutputStepFor instead) and tee ... in list, which is a peek, never this rule. WHERE the fresh value comes from is SinkBufferFor; a target that cannot give one is E08278, so > can never quietly append. The first argument is the built-in types (List, Set, Dict, PriorityQueue, JSON).