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.

[colejohnson66]

delegate<T1, T2, TResult> Op;

This already exists:

public delegate TResult Op<T1, T2, TResult>(T1 a, T2 b);

It's slightly more verbose that your request, but it already exists. Not to mention that System.Func<T1, T2, TResult> also already exists in the BCL. What exactly are you proposing?

[nczsl]

My more standardized definition of functional programming in C# is as follows: First, the definition of operators: In C#, whether it's a function pointer or a method, as long as it's a lambda expression, it's considered an operator, without traditional imperative statements; business logic blocks are constructed by combining operators; based on this, some special considerations are made, which I believe is a better approach. Regarding the development direction of functional programming in C#, in other words, the current approach based on extension methods and LINQ templates is not a purer form of functional programming. Regarding <type-flow>, special designs can be made based on the operator definition, like the example I gave above:

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

I'm just giving an example, but a more accurate description would be to use a new keyword, like 'flow', and change it to:

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

What's the use of this? Because the combination of operators depends on the design of , it is necessary to provide special support for this. This support is just one of all possible supports, and more support should be explored, especially in terms of parallelism. What is the use of adding this flow key annotation? Its main function is to match the return type. It first checks the return type; if a match is found, it automatically returns. It doesn't need to be explicitly written in the lambda expression because, often, for methods like Swap, we can only focus on the implementation of its main functionality, which already occupies the content of the lambda expression. Writing more would turn it into a lambda statement. Therefore, we need to specifically design and support <type-flow>. A set of basic operators can be directly combined on top of <type-flow> to implement any business logic. This is a purer or more standardized form of functional programming in C#. With a purer FP, we can specifically handle it during first-level compilation (roslyn). If an operator has a compile-time identifiable boundary, it can be specially handled. The impact of these handling actions will be limited to that boundary and will not have a wider impact. I think this is very important for the complex multi-scope C#, firstly because it reduces the implementation difficulty, and secondly because it reduces unnecessary impact and potential exception risks. What special things can be done within the scope of FP? Tail recursion support is one example; as for

 delegate<T1..Tn> 

it's certainly much better, as it's something that needs to be supported globally. I've repeatedly explained its advantages: it reduces the complexity of writing code in the FP paradigm, making the code easier to read and write. Of course, we can also discuss how to design concurrency support for C# FP. When you can use OOP, FP, and unsafe in different parts of your business, I think your business will benefit from many things. OOP brings many irreplaceable advantages, while FP extracts the modules that require concurrency, making it easier to implement concurrency optimization. Combining them, each taking advantage of its strengths, is the ideal situation.

[CyrusNajmabadi]

I genuinely do not have any idea what you're talking about.

Everything you've mentioned is already possible in c# today.

We already have delegates. You can adjust compose them in a functional manner. You can already parallelize them in a wide variety of manners.

Your "type flow" has nothing to do with FP. Nothing about FP requires that the type flowing in is the same as the type flowing out. Indeed. That's normally not the case.

If you want this discussion to go somewhere, you need to identify things that c# legitimately can't do (or which is cumbersome to do) and propose concrete, Clear, ideas on how to address those issues.

Putting up walls of text that repeat misinformation about c#, or suggest features that already exist, isn't helpful.

I've repeatedly explained its advantages:

You haven't shown a single advantage over the delegates we already have in the language. Why would I use this over Func<>?

[spydacarnage]

This isn't a discussion - it's a rambling lecture and I, like Cyrus, have no idea what you're actually trying to add to the language, or what problem you're trying to solve.

[CyrusNajmabadi]

a healthy discussion

For there to be a healthy discussion, it is important to actually address the points being made. If you want these features added, you need to convince the team they are worthwhile. That includes, at a minimum:

Explaining well what problems you are trying to solve. Explaining well why the existing solutions are not satisfactory. Working towards a consistent understanding of terms.

As an example, you keep discussing "fp", but your definition of it doesn't seem to align with any sort of established meaning in the PL community. Furthermore, several of your design aspects go against FP Principles. For example, nothing in FP pushes for this sort of "type flow" concept you are espousing. It is the common and expected case that types change across functions.

As another example, you keep mentioning that this week aid in things like parallel processing. But we already have capabilities to do parallel processing of delegates. So in order for your proposal to get attention, you need to explain what the problems are with the current capabilities, and demonstrate strongly that your suggestion actually addresses them.

So far, all of this lacking. Making it so that this discussion has little chance of making it into the language.

Finally, please remember the code of conduct here. Personal attacks are not acceptable.

[nczsl]

If C# undergoes a more standardized functional programming reform, its functional programming support will shift from the current imitation and template-based approach to a rule-based approach. Clearly, these two approaches offer vastly different levels of freedom. Imitation and templates attempt to confine functional programming (FP) applications to pre-defined, fixed mechanisms using a finite level of abstraction, while rule-based approaches allow for greater creative freedom. This would result in a more bounded, rule-based, and purer implementation of FP in C#. Users would build their required business modules using their own operators, designing their own <type-flow>. A set of operators would work together around this <type-flow> to achieve a functional implementation, with the <type-flow> passing through these operators—similar to the concept of a pipeline, and the pipeline processing model originates from functional programming.

[colejohnson66]

Can you provide a block of "before" and "after" C# code to show what exactly your proposal is? As Cyrus and I have mentioned, everything (we've inferred) you're asking for already exists. So what are you saying?