Proposal: Result Binding Expressions (to)

[AlexanderMorou]

Result Binding Expressions (to)

Summary

This proposal introduces result binding expressions for C#. A result binding expression uses the contextual keyword to to evaluate an expression, bind its result to a new local variable (or discard it), and then evaluate a subsequent expression in the scope of that binding. The overall value of the result binding expression is the value of the second expression.

Example:

Console.ReadLine() to line
    Console.WriteLine(line);

In this case, the overall value is void so it yields no final value.

This feature is intended as a C#-native alternative to the pipe forward operator proposals (|> / ?>). It improves dataflow readability without introducing new symbolic operators or placeholder tokens, and it aligns with the language’s existing pattern of contextual keyword-based syntax and explicit variable bindings.

Direct comparison with pipe proposals

The pipe forward operator proposal (#96) describes a chain of method calls like this:

Console.ReadLine()
    |> File.ReadAllBytes()
    |> SHA1.Create().ComputeHash()
    |> BitConverter.ToString()
    |> Console.WriteLine();

Later comment I added suggested using a second operator for positional mechanics (<|):

Console.ReadLine()
    |> File.ReadAllBytes(<|)
    |> SHA1.Create().ComputeHash(<|)
    |> BitConverter.ToString(<|)
    |> Console.WriteLine(<|);

With result binding expressions, the same flow becomes:

Console.ReadLine() to input
    File.ReadAllBytes(input) to fileBytes
    SHA1.Create().ComputeHash(fileBytes) to sha
    BitConverter.ToString(sha) to bitString
    Console.WriteLine(bitString);

To get something similar to the Pipe-forward data-on-the-left, you would just reformat it:

Console.ReadLine()
    to input File.ReadAllBytes(input)
    to fileBytes SHA1.Create().ComputeHash(fileBytes)
    to sha BitConverter.ToString(sha)
    to bitString Console.WriteLine(bitString);

For comparison, the equivalent code in current C# uses explicit locals:

var input = Console.ReadLine();
var fileBytes = File.ReadAllBytes(input);
var sha = SHA1.Create().ComputeHash(fileBytes);
var bitString = BitConverter.ToString(sha);
Console.WriteLine(bitString);

The result binding expression form keeps the dataflow linear and explicit while staying
within the expression grammar.

Motivation

Multi-step transformations often become either deeply nested expressions or a series of explicit local variable declarations. Nested calls can be hard to scan and edit when you get more than a few levels deep. Pipe forward proposals attempt to alleviate this by providing a new operator to forward a value into a call, but after years of discussion they remain unchampioned. Issues include complex parameter placement rules and the need for additional placeholder syntax to achieve explicit control.

Recent C# evolution favors keyword-based constructs (patterns, query expressions, collection expressions) and expression-block features rather than new punctuation. Binding expressions follow this trajectory: they introduce a keyworded form that reuses existing variable semantics and composes with future sequence and expression blocks.

Relationship to existing pipe proposals

This proposal is an alternative to existing pipe forward proposals. Those proposals define new |>, <| and ?> operators and rely on implicit parameter placement rules. Binding expressions instead make the intermediate value explicit via a normal identifier, avoid adding new operators, and support non-call expressions and multiple uses of the bound value. If adopted, result binding expressions would cover the core motivations for pipe operators and render a separate pipeline operator unnecessary.

Detailed design

Core syntax

A result binding expression has the form:

E1 to T x
    E2;

or, with type inference:

E1 to var x
    E2;

E1 to x
    E2;  // shorthand for 'to var x'

E1 and E2 are expressions. x is a local identifier. My preferred formatting is to place to on the same line as E1 and indent the subsequent expression, matching the pipeline shape. But the exact white space wouldn't influence the function. Each binding introduces a new scope for x and then flows into the next expression.

Informal semantics

The result binding expression

E1 to T x
    E2;

behaves as if it were rewritten to a nested block (see champion #9243):

{
    T x = E1;
    E2;
}

The exception to the champion #9243 is E2 may be a void expression, which has no value or data type (not even null.)

Evaluation proceeds as follows:

1. Evaluate E1, including side effects.
2. Declare a new local variable x and initialize it with the value of E1. If an explicit type T is specified, E1 must be implicitly convertible to T. If var or no type is specified, x's type is inferred exactly as for var x = E1.
3. Evaluate E2 in a scope where x is in scope and definitely assigned.
4. The value of the result binding expression is the value of E2.

When the binding designator is _, special discard semantics apply. In E1 to _ E2; the underscore is treated as a discard. E1 is evaluated and its result is ignored; no local variable is introduced and _ cannot be referenced in E2. This special case also allows E1 to have type void, which is otherwise illegal to assign to a variable. Without the discard form, binding a void expression would produce a compile-time error.

Chaining and pipelines

Result binding expressions compose naturally by chaining:

Console.ReadLine() to input
    File.ReadAllBytes(input) to fileBytes
    SHA1.Create().ComputeHash(fileBytes) to sha
    BitConverter.ToString(sha) to bitString
    Console.WriteLine(bitString);

Conceptually this becomes nested blocks where each step introduces a new variable. Names are normal locals: they can be referenced multiple times in subsequent expressions, and nested bindings shadow outer names if needed.

Using the discard form _ allows side-effecting expressions that return void to participate in a chain:

// Compute something and keep the result
Compute() to result
    // Log or perform an action (void result.)
    Console.WriteLine($"Intermediate result: {result}") to _
    // Continue processing the original result.
    SomeTransform(result) to transformed
    Console.WriteLine(transformed);

Void-returning call in a pipeline

Console.WriteLine returns void. Without the discard form, binding the result would be illegal (CS8209); with to _ the call is evaluated for its side effect and the pipeline continues.

Expression vs statement

Binding expressions are expressions and can be used wherever an expression is
allowed. They are also valid as expression statements when the final
expression has a side effect:

Console.ReadLine() to line
    Console.WriteLine(line);

// as an expression producing a value:
var length = Console.ReadLine() to line
    line.Length;

Scope and definite assignment

The binding introduces a new local variable scoped only over the right-hand expression. Each nested binding creates a nested scope. The bound variable is definitely assigned at the start of the right-hand expression. Discards introduce no variable at all.

Typing rules

For E1 to T x E2;:

• Let S be the type of E1. There must be an implicit conversion S → T; otherwise a compile-time error occurs.
• Within E2, x is a local variable of type T and is definitely assigned.
• The type of the entire result binding expression is the type of E2.

For E1 to var x E2; and E1 to x E2;:

• x's type is inferred exactly as in var x = E1;. If inference fails, it fails here.
• The type of the result binding expression is the type of E2.

For E1 to _ E2;:

• _ is a discard. No variable is introduced and _ cannot be used in E2.
• E1 may have any type, including void. The value of E1 is ignored.
• The type of the result binding expression is the type of E2.

Interaction with async and nullability

Binding expressions compose naturally with await and with nullable analysis. For example:

await FetchAsync() to payload
    TransformAsync(payload) to transformed
    SendAsync(transformed);

string? maybeName = GetName();
maybeName to name
    Console.WriteLine(name.Length);

The rules for awaiting and nullable reference types are unchanged; x is treated like any other local.

Examples

Equivalent forms

Nested form:

Console.WriteLine(
    BitConverter.ToString(
        SHA1.Create().ComputeHash(
            File.ReadAllBytes(
                Console.ReadLine()))));

Pipe operator proposal:

Console.ReadLine()
    |> File.ReadAllBytes()
    |> SHA1.Create().ComputeHash()
    |> BitConverter.ToString()
    |> Console.WriteLine();

Binding expression:

Console.ReadLine() to input
    File.ReadAllBytes(input) to fileBytes
    SHA1.Create().ComputeHash(fileBytes) to sha
    BitConverter.ToString(sha) to bitString
    Console.WriteLine(bitString);

Explicit locals:

var input = Console.ReadLine();
var fileBytes = File.ReadAllBytes(input);
var sha = SHA1.Create().ComputeHash(fileBytes);
var bitString = BitConverter.ToString(sha);
Console.WriteLine(bitString);

Logging and metrics

Compute() to value
    Console.WriteLine($"Computed {value}") to _
    Validate(value) to validated
    Persist(validated);

The to _ binding discards the result of Console.WriteLine(...), allowing it to be sequenced before the remaining steps.

Guarded transform

Console.ReadLine() to line
    (string.IsNullOrWhiteSpace(line)
        ? "Empty input"
        : line.ToUpperInvariant()) to display
    Console.WriteLine(display);

Tuples and anonymous types

GetPoint() to p
    (p.X, p.Y) to coords
    Console.WriteLine(coords);

GetUser() to user
    new { user.Id, user.Name } to projection
    Console.WriteLine(projection);

Grammar changes (EBNF)

These grammar changes follow the style of the C# specification’s lexical and syntactic grammars.

Lexical grammar

Add to as a contextual keyword:

contextual_keyword
    : 'add' | 'alias' | 'ascending' | 'async' | 'await'
    | 'by' | 'descending' | 'dynamic' | 'equals' | 'from'
    | 'get' | 'global' | 'group' | 'into' | 'join'
    | 'let' | 'nameof' | 'notnull' | 'on' | 'orderby'
    | 'partial' | 'remove' | 'select' | 'set' | 'to'
    | 'unmanaged' | 'value' | 'var' | 'when' | 'where'
    | 'yield';

Expression grammar

Insert binding_expression as an alternative form of non_assignment_expression:

non_assignment_expression
    : declaration_expression
    | conditional_expression
    | lambda_expression
    | query_expression
    | binding_expression
    ;

binding_expression
    : null_coalescing_expression 'to' binding_designation expression
    ;

binding_designation
    : local_variable_type identifier
    | identifier
    | '_'
    ;

null_coalescing_expression ensures that result binding expressions have lower precedence than ?? and higher precedence than assignment. The right-hand expression is a full expression, following the pattern of the conditional operator.

Statement grammar

No change is required to the expression_statement grammar. Binding expressions may serve as statement expressions when their trailing expression is an invocation or other allowed statement expression.

Drawbacks

• Introduces a new contextual keyword (to) and a new expression form, requiring parser, binder, and IDE support.
• All binding patterns are already expressible today via locals and blocks; the feature improves ergonomics rather than adding new capabilities.
• Discard semantics in result binding expressions require a special case for void: _ discards the value of E1 and permits E1 to be void.

Alternatives

• Continue pursuing pipe operators (|>, ?>): these designs add new operators and rely on implicit parameter placement and optional placeholder tokens. They have not moved beyond discussion in several years.
• Expression blocks: a general solution using blocks with a trailing expression can express the same patterns but is more verbose. Binding expressions can be seen as a lightweight sugar over a common block pattern.
• Status quo: use explicit locals or nested calls. There is no readability improvement in this case.

Unresolved questions

• Should the binding designation allow full patterns (e.g. E1 to (int x, int y) coords E2)?
• Should result binding expressions be permitted in expression trees, and how would they be represented?
• Exact interaction with future sequence or expression block features will need coordination.
• Relaxation of CS8209 may be non-trivial.

[GabeSchaffer]

I prefer the let ... in ... syntax as commonly found in functional languages. Here's a possible C# syntax for your example:

let input = Console.ReadLine(),
    fileBytes = File.ReadAllBytes(input),
    sha = SHA1.Create().ComputeHash(fileBytes),
    bitString = BitConverter.ToString(sha)
in Console.WriteLine(bitString);

Since let is already used to bind a subexpression to an identifier, it's already a rather familiar syntax. The in delineates the binding subexpressions from the result subexpression.

[AlexanderMorou]

I'm not fond of that. Honestly.

That introduces two new uses of the contextual keywords let and in, and further, at that point you may as well be using var. It's also a greater departure from the pipe forward proposal (#96). There's no means to effectuate the inner void scenario:

Compute() to value
    Console.WriteLine($"Computed {value}") to _
    Validate(value) to validated
    Persist(validated);

[GabeSchaffer]

I feel it's usually better to reuse an existing concept rather than to create a new one. For example, when they implemented catch clause filtering, it makes sense that they reused the form that VB had, so it also made sense to reuse it for case guards in switch statements, and then switch expressions. Thus, I think adding a new use for a keyword (contextual or not) is a good idea if it follows the same form.

So if you don't like let name = expression, I suggest expression into name to reuse the into contextual keyword in a manner similar how it's used with join or group.

[timcassell]

I feel like half of the point of pipe forward operator is to not name things that don't need to be named. This just brings the name right back, so it's objectively worse.

[GabeSchaffer]

I agree. Functional languages like F# can use pipelines so successfully because all functions in the ecosystem that are expected to be used with the pipe operators are designed to take their most important argument last.

For example, the insertAt function has the signature Seq.insertAt index value source, allowing you to call it like data |> Seq.insertAt 42 "new item".

This is the opposite of the C# ecosystem where functions are designed for fluent syntax, which requires putting the most important argument first (i.e. extension methods) or as the receiver of a method call.

Furthermore, F# code mostly uses functions rather than method calls, and functions cannot be overloaded. This means there's no need to have a syntax to represent the piped-in value. In C# it would not be useful to have a pipeline syntax that only worked for unary static methods, so it requires having a name for the piped-in value. I've seen proposals for %, $, ?, and others, but none of them are terribly appealing.

[AlexanderMorou]

Agreed, C# isn't F#. #96 is too ambiguous with the weird binding rules. It can be hard enough to figure out what something binds to in C# without an IDE, even with a very clear call tree.

We're not trying to make C# into F#.

That's why an explicit where it goes approach seems logical for C#.

[GabeSchaffer]

That's why an explicit where it goes approach seems logical for C#

The problem with naming the "where it goes" is that coming up with names is hard and parsing the names is extra work for readers. If you had a contextual keyword like value, I think that would be an improvement because C# already uses that to mean "implicit argument", but then your to wouldn't be binding an expression to a name anymore. This is what you'd end up with:

Console.ReadLine() to
    File.ReadAllBytes(value) to
    SHA1.Create().ComputeHash(value) to
    BitConverter.ToString(value) to
    Console.WriteLine(value);

[orthoxerox]

@GabeSchaffer and this brings us back to the original piping proposals, with the only difference being that to is easier to type than |>.

[AlexanderMorou]

Console.ReadLine() to
    File.ReadAllBytes(value) to
    SHA1.Create().ComputeHash(value) to
    BitConverter.ToString(value) to
    Console.WriteLine(value);

I'm sure you can imagine that's... not ideal. You basically have the same term overloaded four times. Not knowing the syntax, you would easily misinterpret the line. Ambiguity is the ruin of a feature.