Proposal: Achieving Full FP Capabilities in C# Through Expression-Based Operators

[nczsl]

Operators in C#: Toward a Complete Functional Expression Model

1. Definition of an Operator

In this document, we define an operator as:

An operator is a function that consists purely of expressions, containing no imperative statements.

In other words, an operator is a semantic subset of a function.
In C#, operators can be defined in any lambda expression form:

// Simple operator
Func<int, int> square = x => x * x;

// Operators can also be assigned to variables
var inc = (int x) => x + 1;

// Expression-bodied members also qualify
int AddOne(int x) => x + 1;

There is no technical difference between an operator and a regular function—
the distinction lies in intent:
An operator represents a pure composable function, not a procedural control unit.
Thus, “operator” is a semantic alias for a kind of function designed for composition and flow.

---

2. The Current FP Capabilities of C#

As of C# 13 / .NET 9, C# already provides nearly all functional programming fundamentals:

Feature	Supported	Description
First-class functions (Lambda, Func, Action)	✅	Fully supported
Pattern matching & expression-bodied syntax	✅	Allows pure expressions
LINQ & extension methods	✅	Enables type flow composition
Immutable types (record, with)	✅	Supports FP data immutability
Higher-order functions	✅	Fully functional
Tail recursion optimization	❌	Not guaranteed or enforced
Generic function pointer (delegate<T1..Tn>)	⚠️	Not directly supported

The last two items are the final missing pieces for a fully functional C#.

---

3. Example: Expression-based Operator Flow via Type Flow

Below is a minimal functional composition example.
We define an interface Ix as the carrier of type flow,
so that operators can connect through the this parameter as a fluent functional chain.

using System;

public interface Ix
{
    int Value { get; }
}

// Concrete implementation
public readonly struct X : Ix
{
    public int Value { get; }
    public X(int value) => Value = value;
}

// Operator definitions — all expression-bodied (no imperative code)
public static class XOps
{
    // Add operator
    public static Ix Add(this Ix x, int v) => new X(x.Value + v);

    // Multiply operator
    public static Ix Mul(this Ix x, int v) => new X(x.Value * v);

    // Recursive operator (pure expression form, non-optimized recursion)
    public static Ix Pow(this Ix x, int n) =>
        n switch
        {
            <= 0 => new X(1),
            1 => x,
            _ => x.Mul(x.Pow(n - 1).Value)
        };
}

public class Program
{
    public static void Main()
    {
        Ix result = new X(2)
            .Add(3)   // => 5
            .Mul(4)   // => 20
            .Pow(2);  // => 400

        Console.WriteLine(result.Value); // Output: 400
    }
}

---

4. What if We Had delegate<T1..Tn>?

Imagine if we could declare generic function pointer types like this:

// Hypothetical syntax
delegate<T1, T2, TResult> Op;

// Define operators directly as type flows
Op<Ix, int, Ix> add = (x, v) => new X(x.Value + v);
Op<Ix, int, Ix> mul = (x, v) => new X(x.Value * v);

// Purely recursive operator composition
Op<Ix, int, Ix> pow = (x, n) => n switch
{
    <= 0 => new X(1),
    1 => x,
    _ => mul(x, pow(x, n - 1).Value)
};

Advantages of this form:

1. More direct — the type signature is the functional flow.
2. No delegate wrapper — more natural and low-level expression of functions.
3. Performance friendly — no Delegate overhead.

---

5. Operators and Type Flow

Extension methods (this parameters) are the foundation of type flow in C#.
They allow any type to define a family of composable operators,
creating a functional expression space directly in the language:

Ix expr = new X(1)
    .Add(2)
    .Mul(3)
    .Add(5)
    .Pow(2);

This is semantically equivalent to a pure mathematical expression.
With a “no imperative statement” constraint, C# achieves full functional expressiveness.

---

6. Summary

Aspect	Current Status	Future Direction
Lambda expressions	✅ Complete	Fully expressive
Type flow mechanism	✅ Complete	Enabled by extension methods
Tail recursion optimization	❌	Should be enabled for lambdas
Generic function pointer	⚠️	delegate<T1..Tn> proposal
Operator semantics	✅	Can be standardized as a subset of functions

Once these two missing mechanisms are implemented,
C# will become a fully functional-capable language—
where all logic can be represented as composable operators without imperative statements.

---

Would you like me to help you add a short proposal header section (like “Motivation”, “Proposal”, “Benefits”, “Open Questions”) in the GitHub issue style before you post it to dotnet/csharplang? It’ll make it match their official RFC tone (like other language proposals).

[nczsl]

With complete FP support, system libraries designed on this foundation for parallelization can be more targeted. Like the current Plinq system library, it can be seen as an important interface to FP. We can leverage FP's inherent concurrency-friendly advantages to better encourage developers to naturally switch to a concurrency perspective. This can help address specific business needs requiring concurrency. It can seamlessly integrate with C#'s object-oriented programming, each leveraging its own strengths. This creates a truly complementary, rather than chaotic, multi-paradigm language. You should notice that many new C# features are now expression-based. This is an optional mechanism. From a narrow perspective, I could say it increases confusion and unnecessary complexity. For example, x?=... introduced in .NET 10 and C# 14 replaces if(x!=null) x=..., which is common in C#. However, from a positive perspective, these can be seen as two paradigms: a traditional command-based paradigm and an FP-based paradigm, right? I believe OOP and FP are equally important; they are both excellent philosophies and paradigms. Furthermore, C# possesses a C++ underlying capability: unsafety. This provides the foundation for writing truly high-performance code in C#. Therefore, based on my current understanding, C#'s unsafety, OOP, and FP are all crucial and should be continuously monitored, maintained, and developed. After long-term, persistent efforts, C#'s infrastructure is now largely complete. Therefore, my suggestion is that C# should focus on providing comprehensive concurrency support for FP, such as adding attribute tags to operator recognition after compilation, and only performing tail recursion on specific operators to prevent the complexity caused by scaling. Of course, this is just my layman's suggestion for your reference.

[CyrusNajmabadi]

Would you like me to help you add a short proposal header section (like “Motivation”, “Proposal”, “Benefits”, “Open Questions”) in the GitHub issue style before you post it to dotnet/csharplang? It’ll make it match their official RFC tone (like other language proposals).

....

I strongly recommend you restart this discussion. Clearly layout the real world problems that the existing language isn't suitable for, and why and how these language ideas are critical to address them.

[nczsl]

Would you like me to help you add a short proposal header section (like “Motivation”, “Proposal”, “Benefits”, “Open Questions”) in the GitHub issue style before you post it to dotnet/csharplang? It’ll make it match their official RFC tone (like other language proposals).

....

I strongly recommend you restart this discussion. Clearly layout the real world problems that the existing language isn't suitable for, and why and how these language ideas are critical to address them.

As long as you're not threatening to easily shut down this discussion, it's fine! I don't care that much; the focus is on the topic itself. Perhaps your reminder was well-intentioned, but I haven't realized some points yet. So let's discuss style or code of conduct once I catch up with your focus. I prefer to concentrate on the issue itself. Thank you!

[AmrAlSayed0]

There is no technical difference between an operator and a regular function

The || (or) operator short-circuits the evaluation of its parameters. An equivalent normal Or function would evaluate all parameters first and then perform the logic.

[timcassell]

That sounds like it could be a useful feature on its own. We got interpolated string handlers that can defer the string evaluation based on a boolean, I could imagine a more general feature to defer all argument expression evaluations.

[nczsl]

Proposal: <type-flow> Extension Semantics for Functional Composition in C#

Author

@maogang — original author of discussion #9817

---

Motivation

C# has already taken significant steps toward functional programming (FP) — we have operators (functional-style combinators), lambda expressions, pattern matching, and switch expressions.

However, when we attempt to construct complete algorithms (for example, a sorting algorithm) purely in FP style, we encounter a critical missing piece — <type-flow>.

This proposal aims to define what true FP composition means in C#, and how <type-flow> can serve as a foundational mechanism for achieving it — without breaking existing imperative semantics.

---

The Example Problem

Let’s start with a simple functional sorting example:

int[] Swap<T>(int[] source, int i, int j) 
    => (source[j], source[i]) = (source[i], source[j]);

At first glance, Swap looks like a functional operator — it transforms data (int[]) and returns the same type, maintaining flow continuity.
But when we start composing it with other functional operators, the limitation becomes apparent:

int[] Move1(int[] source, int i)
    => i < source.Length - 1
        ? source[i] > source[i + 1]
            ? Swap(source, i, j)
            : Move1(source, i++)
        : source;

int[] Move2(int[] source, int i)
    => i < source.Length
        ? Move1(source[i..], i)
        : Move2(source, i++);

In this example, Swap fails to behave as a composable FP operator — it performs a side-effect (swapping) but cannot express the operation and return the same flow in a purely declarative way inside a lambda expression.

---

The Missing Piece: <type-flow>

The root problem is the lack of a flow identity within the type system — what we can call a <type-flow>.

In functional composition, every operator in the chain shares a common data flow type (e.g., T, IEnumerable<T>, etc.). In C#, although this-based extension methods simulate this pattern, they are syntactic sugar over static methods — not type-flow aware operators.

To fix this, we could introduce a rule or marker that explicitly designates a parameter as the flow carrier of a function — something like:

int[] Swap(this int[] source, int i, int j) => ...

Here, this does not merely mean “extension method”; rather, it signals automatic flow return — the method guarantees to return the same flow type as its first parameter, enabling FP-style chaining without mutating context.

This mechanism would make it possible to keep Swap, Move1, Move2, etc., composable under a common <type-flow> type identity.

---

Design Implications

Once a method parameter is marked as <type-flow> (using something like this), several questions arise:

1. Return Type Matching

Should the return type always match the flow type (T)?
For example:

T M<T>(this T t, ...)

Or can it be:

void M<T>(this T t, ...)

under certain conditions?

---

2. Delegate Identity

Should such functions be interpreted as:

delegate<int, int>

or

delegate<int, int, int[]>

?

My position is that the first form (delegate<int, int>) should be preferred, allowing implicit flow continuity.

---

3. Signature Enforcement

If a function is marked with <type-flow>, should its signature be enforced to maintain the flow type identity? Possibly yes, but only when the function conforms to the operator definition (i.e., a pure expression returning the flow).

---

4. Non-Pollution Rule

These rules should only apply when the function is explicitly recognized as an operator (pure expression form). Traditional imperative methods remain unaffected — ensuring this mechanism does not pollute command-style syntax.

---

Summary

Concept	Description
<type-flow>	The identity of the flow type used in FP composition
Goal	Enable automatic return and chaining of the same flow type
Mechanism	Use a this-like marker to define flow-carrier parameters
Benefit	Makes FP-style algorithms (e.g., sorting) fully composable and declarative
Compatibility	Does not alter existing imperative semantics

---

Conclusion

C# already has most of the ingredients for functional expression — operators, lambdas, and compositional syntax. What we need now is a formal mechanism for type flow continuity — a <type-flow> identity that makes expression-based algorithms both natural and composable.

This proposal keeps FP purity, enables declarative design, and integrates smoothly with the existing type system.

---

Discussion welcome on signature semantics, return-type enforcement, and the definition of a "flow operator" in the C# type system.

[nczsl]

---

## Extending the Proposal: FP-Specific Compilation and Parallelization Semantics

### 1. Functional Operator Metadata at Compile Time

If C# can recognize certain methods as *functional operators*,  
then part of their **first-level compile-time representation** could carry *operator-level metadata* —  
that is, automatic annotations or attributes generated by the compiler.

This metadata could help the compiler and runtime distinguish FP-composable methods  
from ordinary imperative methods, thereby isolating the new rules  
and preventing excessive system-wide complexity.

**Example Concept:**

```csharp
[FunctionalOperator]
int[] Swap(this int[] source, int i, int j) => ...

Such annotations could allow the compiler to:

• Optimize these operators differently (e.g., inline chaining, remove defensive copies).
• Track <type-flow> dependencies for correctness.
• Restrict side-effects (enforcing pure expressions where applicable).

In short, this mechanism keeps the FP behavior self-contained
and prevents interference with the broader imperative model.

---

2. Business-Level Parallelism and FP Integration

From the previous sorting example, we observed a path-dependency problem —
sorting is generally not a good candidate for parallelization due to dependency between iterations.

However, some operations are naturally parallel-friendly.
For example:

int Sum(this int[] source);

This kind of operator can safely execute in parallel since
its aggregation is associative and independent per segment.

---

3. Introducing Lightweight Parallel Directives

For such FP-friendly operations, we could introduce
lightweight parallel execution directives —
simpler and more direct than PLINQ-style templates.

The goal is to make parallel invocation expressive and declarative,
without requiring external frameworks or boilerplate.

Possible idea (syntax to be discussed):

[Parallel]
int Sum(this int[] source);

or even more dynamically:

int Sum(this int[] source) parallel => ...

This lets developers declare business-level knowledge —
that this operator can or should run in parallel —
without having to change its overall FP structure.

---

4. Contextual Parallelization from Business Semantics

Some operations — like element-wise addition — are also semantically parallel.
The developer, by understanding business logic,
knows these can safely run in a SIMD or multithreaded way.

For example:

int[] AddElements(this int[] a, int[] b);

A type-level or keyword-based mechanism could make it trivial
to activate both parallel and SIMD modes when appropriate.

This naturally fits into the FP world,
where operations are context-free, side-effect-free, and data-flow driven.

---

5. Summary of This Section

Concept	Description
FP Operator Metadata	Allow compiler-generated annotations to mark pure FP operators
Scope Isolation	Keep new semantics limited to FP, avoiding global language pollution
Business-Driven Parallelism	Let developers declaratively mark operations as parallelizable
SIMD/Vector Enablement	Provide easy activation of vectorized execution for element-wise operations
Goal	Empower functional pipelines with parallel control at expression level

---

6. Discussion Points

• How should compiler or runtime interpret [Parallel]?
  Should it map to Parallel.For, Task, SIMD, or adaptive strategies?

• Can <type-flow> metadata automatically infer when operations are purely associative,
  and thus safely parallelizable?

• Could the type system itself express parallel capability as a trait,
  e.g., T : IParallelizable<T>?

---

Conclusion for this Part

The core idea is to give C# developers fine-grained FP-level control over parallel execution,
based on business context rather than framework constraints.

This continues the spirit of <type-flow> —
keeping execution semantics transparent, composable, and expression-based.

---

[nczsl]

In the earlier sorting example, the algorithm shows a path dependency, which is not suitable for parallel execution.

However, consider another case:

int Sum(this int[] source);

This kind of operation is naturally parallelizable.

So, I’d like to propose a more flexible parallel instruction mechanism that allows such operators to run in parallel without relying on a fixed framework like PLINQ.

I don’t have a full syntax design yet — open to discussion.

Business-Driven Parallelism

In many real-world cases, the caller can determine whether an operation is parallelizable —
for instance, element-wise addition:

int[] AddVector(int[] a, int[] b);

If we design something like:

a op[parallel] b

then such operations could automatically execute in parallel.

The op[] syntax could even accept parameters, for example:

a op[parallel, simd] b

This allows the developer to express that the operation should run with parallelization and SIMD acceleration —
perfectly aligned with FP’s nature of data-driven computation and pure transformation semantics.

The emphasis here is not to force parallelism, but to make it natural and accessible at the operator level, where the business context already knows what’s safe to parallelize.

Summary

To summarize, this proposal explores:

Extending FP composability via a concept.

Allowing operator functions to auto-return their flow type via a this-like marker.

Restricting FP extensions to isolated compile-time scopes.

Enabling intuitive and business-driven parallelism via operator-level syntax (op[parallel], op[simd]).

These extensions could help C# move toward a more expressive, composable, and performance-friendly FP model — without compromising existing imperative semantics.