This is not just as easy to read as evidenced by the number of languages supporting this feature. Additionally, this is not as readable because it doesn't make it clear what the dataflow is.

You can derive basically derive the pipeline operator without any regard to functional programming by first recognizing that coming up with names is hard. One idea to solve this is to just keep reassigning the name variable imperatively. That solution has the problem in a static typed context if you are changing the type (this can be solved by allowing shadowing within a block as with Rust). However, reassignment without static types is clunky if the name is long and without shadowing introduces mutation which reduces referential transparency.

@eyalalonn
I did provide a more thorough way to resolve the issue I have with the proposal.

I believe it's vital to not lose information (from the reader's viewpoint) as the details pass from one method to another. When you read it in the proposal's approach, you assume the first parameter is taken up by the pipe-forward -unless- it's a parameter array, -unless- the forwarded value is also an array of the proper type for that parameter array. Lacking a symbol to represent that forwarded value means the code is less clear.

My biggest qualm here is control. You're giving up control over the output through the pipe-forward. What if you need to cast the result, mutate the result or what have you. I can already see the issues flowing in from people saying it's confusing. How would this interplay with tuples? What if we wanted the tuple result to span across all parameters of the target method, or if you needed to reorder the values, discard one or more, or what have you.

The proposal is incomplete. Sure, other languages use it, but just because it's used elsewhere doesn't necessarily mean it needs to be in C#.

From a readability stance, complex call chains are better served being rewritten, storing important bits of data as variables so it's clearer to the reader what you are trying to do.

Code should be able to be read and quickly assessed. While the flow-inversion of the pipe-forward operator has benefit in that direction, take this example:

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

Because SHA1.Create has an overload that takes zero arguments, and there's no clear point that says 'take this parameter', that looks like it should call the parameter-less version of the method.

I say this from maintaining my own code: this thirty method call chain makes sense today, but what about in two months, six months, two years, or even ten? I guarantee you, the more code you write, the less your old code will make sense [at a glance]. In code maintenance: clarity is king.

@AlexanderMorou

The proposal is incomplete. Sure, other languages use it, but just because it's used elsewhere doesn't necessarily mean it needs to be in C#.

That's not how things work and you can see that they take language features very seriously.

From a readability stance, complex call chains are better served being rewritten, storing important bits of data as variables so it's clearer to the reader what you are trying to do.

That's true "complex call chains are better served being rewritten" and in many situations when people are doing this the methods are self explanatory but atm we can't express it differently in the language so we either introduce different extension methods that comes with unnecessary costs, use temporary variables that really don't help one bit in readability they exists just to break the calls into steps or chain the calls that makes it unreadable so between all these choices the forward operator is a great tool to deal with the problem.

var lines = Console.ReadLine();
var linesAsBytes = File.ReadAllBytes(lines);
var linesHash = SHA1.Create().ComputeHash(linesAsBytes);
var linesHashAsString = BitConverter.ToString(linesHash);

Console.WriteLine(linesHashAsString);

Versus:

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

I think that the latter is more readable.

My biggest qualm here is control.

I'm pretty sure that once someone will decide to champion it and the LDT will decide that the feature is important enough they will adjust it to cover 80% of the cases if not all to match their satisfaction and the majority of customers.

The proposal is incomplete.

Like all proposals, you have to start somewhere and iterate. 😃

Because SHA1.Create has an overload that takes zero arguments, and there's no clear point that says 'take this parameter', that looks like it should call the parameter-less version of the method.

They can always introduce an implicit variable or some sort of syntax to address this so it might look something like this:

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

I'm not saying it should be triple dots but it's an option, point is like I said you have to start somewhere and then iterate, nothing is set in stone.

Why not just the classic way:

var line = Console.ReadLine();
var data = File.ReadAllBytes(line);
var hash = SHA1.Create().ComputeHash(data);
var hashStr = BitConverter.ToString(hash);
Console.WriteLine(hashStr);

And you save a few keystroke (not that really matter)

Why not just the classic way:

var line = Console.ReadLine();

var data = File.ReadAllBytes(line);

var hash = SHA1.Create().ComputeHash(data);

var hashStr = BitConverter.ToString(hash);

Console.WriteLine(hashStr);

And you save a few keystroke (not that really matter)

The problem I personally find with this, which would be solved by the pipe operator, is that for each call you have to repeat the same thing 3 times: 'ReadLine' function says I am reading a line, declaring a variable named 'line' says I have a line and then next method references the variable as 'line' again.

It's just a few more characters, but it repeats on each call.

Also, when programming, I find that I can be in two different states of mind: declarative and imperative.

When I write these chained methods my mind is usually in the "declarative" mode, I don't think about the implementation details, but try to describe what result I expect. But having to write same thing 3 times puts my mind back into imperative mode, where I start seeing functions, variables, parameters, etc.

It's distracting.

How about this?

Console.ReadLine() as var line
=> File.ReadAllBytes(line) as var data
=> SHA1.Create().ComputeHash(data) as var hash
=> BitConverter.ToString(hash) as var hashStr
=> Console.WriteLine(hashStr);

I'd like to see something like this where you could use pattern matching and have access to the previous results, or perhaps something more similar to LINQ. With possibly Console.ReadLine() => Console.WriteLine; for single-parameter methods

I like the idea of being able to name variables myself, but I hope to also introduce the concept of the value keyword from auto-implemented properties.

x |> value?.ToString() |> WriteLine
can be expanded at compile time to:

WriteLine(x?.ToString())

@Xyncgas this is useful for any of those development domains.

@resnyanskiy

that is what you should to do. And less prose from you here, please.

This behavior is not acceptable per the code of conduct of this repository.

If you have specific examples then please provide them. It is not the job of anyone on this repository to flush out your ideas for you. If you want to get into the details of how a pipe operator could perform uncurrying then please do so. However, the C# does not perform optimization such as inlining, for many reasons including that most functions are defined outside of the current assembly and the compiler has no access to any source to inline, but also because optimization at the compiler level makes it more difficult for optimization at the runtime level to work properly.

As far as I know, inlining the code in other methods is something the C# compiler was never designed for and should never do. What else than "uncurrying" could be done with it?

that is what you should to do. And less prose from you here, please.

@resnyanskiy this is not acceptable behavior on this repository. Please follow our code of conduct, which includes being respectful to others. You have multiple comments in this thread that are either borderline or completely outside the bounds of this principle.

@resnyanskiy

Why couldn't Roslyn be involved?

I and others already answered that question (quoting a paragraph from my previous post):

Furthermore, in general, it's better to optimize after the compilation, like, during JIT, than during compilation, because language-specific optimizations only benefit that language, whereas runtime optimizations benefit all languages (or even custom generated IL). (PS. This is in addition to the very important reason outlined by @AlexanderMorou - that JITter has much more information, like hardware and OS and what-not, which isn't available during language-to-IL compilation on the developer's machine or build server.)

As far as I know, inlining the code in other methods is something the C# compiler was never designed for and should never do. What else than "uncurrying" could be done with it?

I think he means that with the pipe operator, C# would be able to output IL which skips the local declaration, and save the "move the value from the CPU register to the stack and back". However, this is incorrect; pipe operator should work with instance methods, for example, and it requires this reference to be pushed before the first argument (which would be the pipe-forwarded value), thus prohibiting this theoretical IL-output optimization from happening for instance method invocations. *
However, regardless of this issue, in general, this whole conversation is moot because this is already done by the runtime and there is no need to do anything here.

• PS. Also, there is no one-to-one mapping between IL stack and IL locals, and actual x64 stack and CPU registers.

looking like Haskell is a feature in my book

I continue to experiment.

var value = 777
    .Chain( i => { } )
    .Pipe( i => i.ToString() )
    .If( i => i != null )
    .If2( i => i != null )
    .Chain2( i => { } )
    .Pipe2( i => i.ToString() );

    public static class CSharpExtensions {

        // Chain
        [MethodImpl( MethodImplOptions.AggressiveInlining )]
        public static T Chain<T>(this T value, Action<T> callback) {
            callback( value );
            return value;
        }
        [MethodImpl( MethodImplOptions.AggressiveInlining )]
        public static TResult Pipe<T, TResult>(this T value, Func<T, TResult> converter) {
            return converter( value );
        }
        [MethodImpl( MethodImplOptions.AggressiveInlining )]
        public static Option<T> If<T>(this T value, Func<T, bool> predicate) {
            if (predicate( value )) return new Option<T>( value );
            return default;
        }

        // Chain
        [MethodImpl( MethodImplOptions.AggressiveInlining )]
        public static Option<T> Chain2<T>(this Option<T> value, Action<T> callback) {
            if (value.HasValue) callback( value.Value );
            return default;
        }
        [MethodImpl( MethodImplOptions.AggressiveInlining )]
        public static Option<TResult> Pipe2<T, TResult>(this Option<T> value, Func<T, TResult> converter) {
            if (value.HasValue) return new Option<TResult>( converter( value.Value ) );
            return default;
        }
        [MethodImpl( MethodImplOptions.AggressiveInlining )]
        public static Option<T> If2<T>(this Option<T> value, Func<T, bool> predicate) {
            if (value.HasValue && predicate( value.Value )) return new Option<T>( value.Value );
            return default;
        }

    }

Note that unfortunately this requires an Option type.
I don't know if the compiler will be able to optimize this.
https://www.nuget.org/packages/Option.Pro

P.S.
Damn, method overloading doesn't work as I expected!!!

@Denis535 I'm not trying to get you demotivated but this is definitely not the place for it! you can create a repo and do your experiments there, and share a link in a comment. This is the repo to the C# language design, people here are probably more interested having this feature baked into the language! as opposed to baked into the framework or a library.

p.s. I'm pretty sure you misunderstand this feature based on your comments and code.

@Denis535 the pipe operator is just about function composition. Here are some basic extensions if we want an import

https://github.com/TomyDurazno/PipeExtensions/blob/master/PipeExtensions.cs

@Denis535 I'm not trying to get you demotivated but this is definitely not the place for it! you can create a repo and do your experiments there, and share a link in a comment. This is the repo to the C# language design, people here are probably more interested having this feature baked into the language! as opposed to baked into the framework or a library.

I just wanted to show that a more detailed syntax is better suited for CSharp.
I don't want to see Haskell-like syntax in CSharp.
But that's just my opinion.
Maybe I'm wrong.

I disagree. Current expressions have no such "quick returns", and they can get arbitrarily large. Pipes simply re-arrange those expressions so that their order of execution matches what is written.

I see @AlexanderMorou's comment now suggesting the use of <| for exactly the same purpose.
My example would instead look like this, if I'm understanding it correctly.

Console.ReadLine() |> Console.WriteLine(); // Echoes what the user types.
Console.ReadLine() |> Console.WriteLine(<|); // Exactly the same as above

This addresses my concern while also avoiding name collisions.

Also @lostmsu with ! used in the same way. This is used elsewhere (null suppression, not equals), but how this symbol is used elsewhere is sufficiently different where I don't think there'd be a conflict.

We could of course also use $_ to copy PS, but I think finding something that feels natural in C# should take priority.

I see @AlexanderMorou's comment now suggesting the use of <| for exactly the same purpose. My example would instead look like this, if I'm understanding it correctly.

Console.ReadLine() |> Console.WriteLine(); // Echoes what the user types.
Console.ReadLine() |> Console.WriteLine(<|); // Exactly the same as above

This addresses my concern while also avoiding name collisions.

That 'input' syntax would also allow the forwarded value to be put into the correct parameter explicitly

 range = Console.ReadLine() |> int.Parse(<|) |>  Enumerable.Range(1, <|) ; 

<Note, not expressing string endorsement for this idea, just trying to clarify what exactly the parent meant, the person who reacted with 'confused face' is probably right ...

I like this one, its simple and inuitive.
Its similar to the proposed hack pipes for javascript. https://github.com/tc39/proposal-pipeline-operator

You can make your own

extension<T, U>(T)
{
    public static U operator |(T x, Func<T, U> f) => f(x);
}

So the value proposition here has changed significantly since this issue was created.
The main problems right now are:

• Partial application is clunky. Requires wrapping in a lambda.
• You have to overload an existing operator with a different established meaning.

Consider:

int Sum(int x, int y) => x + y;
var r = 10 | ((x) => Sum(x, 5));

If we could define custom ops and had a way to leave "holes" in invocations it could look like this:

var r = 10 |> Sum(?, 5);

C++ recently relegated the ugly << and >> overloads for I/O to secondary status and introduced the new std::println. In other words, C++ has proven that overloading an operator for completely unrelated purposes is bad.

C++ is a cascade of bad design, but the problem with the stream approach wasn't the aesthetics of <<.

If you only implemented features that felt right at a glance

This is howi try to already most things in the language. Not always possible, but it's safe to say that it's a prime factor for me.

I don't know what you mean by this. The flow is explicit. Unlike the imperative code.

The imperative code is super clear. I have easy names that I can anchor on and track both at declaration and use site.

It's semantically the same, just less cluttered, less indirection.

x.Select(selector).Select(selector)
x |> selector |> selecto

I think I strongly disagree with this, and this is great example why. The reuse of |>
And ? Make it seem like the same thing is flowing through. When that's not the case. Different names and clear declarations of values makes it clear that that's not the case.

Make it seem like the same thing is flowing through.

What? How?
The BCL LINQ operators are monadic, but that's not a requirement of LINQ. And even so, what the monad wraps can change just fine.
There's C# code in production that does from x in Call() from y in Call2(x) select y.

Let's separate the operator from partial application. They are orthogonal features.

dotnet lab

We only need an operator with proper precedence and this will be perfectly reasonable to do. Well, maybe not that exact thing, but we can go ahead and do our functional stuff in peace.

x.Select(selector).Select(selector)
x |> selector |> selector

I think somethings gone wrong here?
shouldnt that be Select not selector?
x |> Select() |> Select()
x |> Select(#) |> Select(#)
Unless im missing something?
also # is probably a better choice for the pipe output symbol than ? as ? already has a use, unless im misunderstanding what your using it for?

I was making a point about Select effectively already being a pipe operator.

You can define it as

extension<T, U>(T x)
{
    public U Select(Func<T, U> selector) => selector(x);
}

For IEnumerable<T> it is defined as functor map where it operates on some inner value and doesn't change the outer type, so Cyrus reasonably objected.

Example

The symbol used for partial application is unimportant at this juncture. It just risks bikeshedding when there isn't even interest from the LDT. I use ? because it's what I use in my own language, so it's familiar. I think # is probably unlikely. It's used for preprocessor directives.

My preference is @@.

public string Foo(int value)
    => Do(value)
    |> Some(@@)
    |> Thing(@@);