Deprecations and sunsets

Deprecation means that a callable or usage pattern remains available for compatibility but should not be used in new expressions. Deprecation is effective now; a sunset is the separate version in which removal is planned.

Deprecated language names

Callable and alias deprecations appear together because both are language names that should be replaced. Replacement compatibility distinguishes a behavior-preserving rename from a migration that needs review.

Kind	Deprecated name	Use instead	Replacement compatibility	Sunset
Function	append	suffix	No — The replacement preserves null input; run null-to-empty first to retain the deprecated function's behavior.	Expressif 3.0
Function	append-new-line	suffix-new-line	No — The replacement preserves null input; run null-to-empty first to retain the deprecated function's behavior.	Expressif 3.0
Function	append-space	suffix-space	No — The replacement preserves null input; run null-to-empty first to retain the deprecated function's behavior.	Expressif 3.0
Function	prepend	prefix	No — The replacement preserves null input; run null-to-empty first to retain the deprecated function's behavior.	Expressif 3.0
Function	prepend-new-line	prefix-new-line	No — The replacement preserves null input; run null-to-empty first to retain the deprecated function's behavior.	Expressif 3.0
Function	prepend-space	prefix-space	No — The replacement preserves null input; run null-to-empty first to retain the deprecated function's behavior.	Expressif 3.0
Accumulator alias	implode	concat	Yes — same implementation	Expressif 3.0

For example, replacing implode with concat changes only the name. Replacing append with suffix changes null handling; use null-to-empty | suffix(...) when the deprecated behavior must be preserved.

Deprecated usage patterns

These forms implicitly supply arguments to a nested callable. Replace that usage with explicit tuple binding; the surrounding operators and target callable names remain supported. Removal planned for v3.0.

Shorthand replacements below are supported on the current development line. For an older installed release, check its tuple-binding support before using tilde syntax. The explicit-expression alternatives apply where their stated context and signature conditions hold. Automatic migration requires a resolved eligible signature and compatible invocation values; unknown tuple shapes or incompatible values withhold automatic replacement.

adjacent: implicit argument binding

Rule: implicit-tuple-binding-adjacent

A single bare callable with a binary signature relies on the previous element being injected as its argument and the current element as its pipeline input.

Deprecation: Active now. Introducing release version pending; implemented in the deprecation commit (not yet tagged for release).

Sunset: Removal planned for v3.0

The operation receives T(previous, current): $0 is the previous element and $1 the current element of the array supplied to this adjacent call. Preserve current minus previous; the reverse shorthand changes operand direction. Migration documentation.

Deprecated usage	Use instead	Availability and applicability	Result
{1, 2, 5} | adjacent(subtract)	{1, 2, 5} | adjacent(~subtract)	Supported on this development line. The resolved callable signature accepts explicit tuple binding and each invocation is compatible.	{1, 3}
{1, 2, 5} | adjacent(subtract)	{1, 2, 5} | adjacent($1 | subtract($0))	Supported on this development line. For numeric subtraction with T(previous, current), including runtimes without tilde shorthand.	{1, 3}

chunk-while: implicit argument binding

Rule: implicit-tuple-binding-chunk-while

A bare callable with a binary signature, alone or leading an open pipeline, relies on the complete current chunk being injected as its argument and the candidate as its pipeline input.

Deprecation: Active now. Introducing release version pending; implemented in the deprecation commit (not yet tagged for release).

Sunset: Removal planned for v3.0

The operation and following argument expressions use T(currentChunk, candidate): $0 is the complete current chunk, excluding the candidate, and $1 is the candidate from the array supplied to this chunk-while call. Later stages retain that tuple as argument context while receiving the preceding result as pipeline input. The previous/current contract is replaced; pairwise numeric conditions must select $0 | last explicitly. Automatic rewriting is withheld because chunk boundaries depend on runtime predicate results. Migration documentation.

Deprecated usage	Use instead	Availability and applicability	Result
{{1, 2}, {3}, {4, 5}} | chunk-while(zip | cardinality | less-than(2))	{{1, 2}, {3}, {4, 5}} | chunk-while(~zip | cardinality | less-than(2))	Supported on this development line. Each candidate is an array; zip pairs its elements with elements of the complete current chunk.	{{{1, 2}, {3}}, {{4, 5}}}
{{1, 2}, {3}, {4, 5}} | chunk-while(zip | cardinality | less-than(2))	{{1, 2}, {3}, {4, 5}} | chunk-while($1 | zip($0) | cardinality | less-than(2))	Supported on this development line. The operation context is T(currentChunk, candidate), with an array candidate and an array of accepted elements.	{{{1, 2}, {3}}, {{4, 5}}}

map-over: implicit argument binding

Rule: implicit-tuple-binding-map-over

A single bare callable relies on each supplied item being injected as arguments, expanding an item tuple by one level, with the map-over pipeline input as the callable input.

Deprecation: Active now. Introducing release version pending; implemented in the deprecation commit (not yet tagged for release).

Sunset: Removal planned for v3.0

The leading binding receives T(outer input, ...item arguments). Only the supplied item tuple expands once; outer input and nested tuples remain intact. Following argument expressions retain the supplied item context, not the prepared invocation tuple. Migration documentation.

Deprecated usage	Use instead	Availability and applicability	Result
5 | map-over(subtract, {10, 11})	5 | map-over(subtract~, {10, 11})	Supported on this development line. The resolved signature and supplied item shapes are compatible with tuple binding.	{-5, -6}
20 | map-over(subtract, {T(1, 2), T(3, 4)})	20 | map-over(subtract~, {T(1, 2), T(3, 4)})	Supported on this development line. These item tuples supply the two supported subtraction arguments without recursively flattening nested values.	{18, 8}

map-with: implicit argument binding

Rule: implicit-tuple-binding-map-with

A single bare callable relies on the map-with pipeline input being injected as one argument, with each supplied item as the callable input.

Deprecation: Active now. Introducing release version pending; implemented in the deprecation commit (not yet tagged for release).

Sunset: Removal planned for v3.0

The leading binding receives T(outer input, item); prefix binding invokes item | f(outer input). The whole outer input and supplied item are preserved. Following argument expressions retain the supplied item context. Migration documentation.

Deprecated usage	Use instead	Availability and applicability	Result
5 | map-with(subtract, {10, 11})	5 | map-with(~subtract, {10, 11})	Supported on this development line. The resolved callable accepts the whole outer input as one argument and the supplied item as its pipeline input.	{5, 6}

Existing complete reduce and split-while expressions are not deprecated solely because those operators support shorthand binding.

Callable and alias entries come from the function, predicate, and accumulator catalogs. Usage entries come from the same structured lifecycle rules embedded in the runtime and exposed by semantic diagnostics for language-server migration support. DeprecatedSince records the actual introducing release when published; a pending release version does not make an active deprecation pending. This page does not describe the lifecycle of the public .NET API.