Proposal: Pipe-forward operator

[alrz]

Ported from dotnet/roslyn#5445

Pipe-forward operator

Summary

Lets you pass an intermediate value onto the next method, in the same order that they will be evaluated.

Proposal

When you are chaining multiple methods to one another you might end up with something like this:

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

Using pipe-forward operator it can be written as (in the same order that they will be executed):

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

Since C# is not exactly a functional language, forwarding to the last parameter wouldn't be useful most of the time, because not every method parameters are written with a sensible order for currying purposes. Also, in functional languages we don't have overload resolution, that is, functions are often numbered like iter1, iter2, etc. In C#, however, we can utilize overload resolution and optional/named arguments, to be able to use this in a wide variety of use cases without introducing any other mechanism.

Argument Lists

Applicability of the argument list in the RHS is roughly defined as follow:

Empty argument list

It's a compile-time error if the method in the RHS doesn't accept any arguments.

Action<int> a = q => {};
arg |> a;       // ERROR

void M() {}
arg |> M();     // ERROR

void M(int a) {}
arg |> M();     // OK

Positional arguments

Each positional argument will be matched in order to the list of method parameters. If there was more positional arguments than number of parameters minus one and the last parameter was not params, the method is not applicable. Otherwise, the LHS goes to the last element in the expanded form.

void M(int a) {}
arg |> M();     // M(arg);

void M(params int[] a) {}
arg |> M();     // M(new[] { arg });
arg |> M(1);    // M(new[] { 1, arg });
arr |> M();     // M(arr);

Optional arguments

In case of optional arguments, LHS goes to the leftmost unspecified parameter which has the identical or implicitly convertible type of LHS. If there was a more specific parameter, then we skip other less specific ones.

void M(int a, int b, double c = 0, int d = 0) {}
4d |> M(2, 3);  // M(2, 3, 4d, 0);
4  |> M(2, 3);  // M(2, 3, 0, 4);

Named arguments

Each named argument will be matched to a parameter with the given name. If one of the named arguments failed to match, or matches an argument already matched with another positional or named argument, the method is not applicable. Otherwise, we'll do as above.

void M(int a, int b, int c) {}
void M(int a, double b, int c) {}
1  |> M(2,  c: 3);      // M(2, 1, 3);
1d |> M(a: 2,  c: 3);   // M(2, 1d, 3);

The method is not applicable (1) if more than one of non-optional parameters are not specified, (2) LHS was not implicitly convertible to its type (3) or it's a ref or out parameter.

Evaluation order

The LHS will be evaluated in the lexical order, i.e. first.

F() |> M(G());  // var t = F(); M(G(), t);

Variations

Null-conditional forwarding

(From dotnet/roslyn#8593)

var r = Foo.Bar?.Baz ?> F() ?? false;
var r = ((temp = Foo.Bar?.Baz) != null ? F(temp) : null) ?? false;

Function F won't get executed if the forwarded value was null, and also, Foo.Bar?.Bar only evaluates once. Note that the value forwarded to the target function F is of a "non-nullable type".

Just like ?. operator, you don't need to use ?> if the target function doesn't return a nullable value, so for chaining you should use the regular |> operator to not perform an additional null-checking.

Syntax

relational-expression:
 forward-expression

statement-expression:
 forward-expression

forward-expression:
 relational-expression |> shift-expression
 relational-expression ?> shift-expression

The expression on the right-hand-side must be one of the kinds that a value can be forwarded to, namely, invocation-expression, object-creation-expression, an await-expression that contains any of applicable expressions (recursively), etc.

Examples

var r = nullable?.Foo.Bar ?? value;
var r = (nullable != null ? nullable.Foo.Bar : null) ?? value;

var r = value |> F() ?> G() ?? value;
var r = ((temp = F(value)) != null ? G(temp) : null) ?? value;

var r = nullable ?> F() |> G() ?? value;
var r = (nullable != null ? G(F(nullable)) : null) ?? value;

var r = nullable ?> F() ?> G() ?? value;
var r = (nullable != null ? (temp = F(nullable)) != null ? G(temp) : null : null) ?? value;

var r = value |> foo?.F();
var r = foo?.F(value);

var r = nullable ?> foo?.F();
var r = nullable != null ? foo?.F(nullable) : null;

[resnyanskiy]

There are some new questions above. All about "why do we need it?".

Just want to point here - as for me, a pipeline/composition in C# should give the ability for the compiler to uncurry /inline functions in some cases and therefore increase performance of the application (reduce stack allocations, and so on).

Just a 'syntax sugar' with the only purpose - reduce some lines of code - not have big sense.

void Main() => x |> A |> B |> C;

int A(x) => x + 1;
int B(x) => x + 2;
int C(x) => x + 3;

->

void Main() => D(x); 

int D(x)
{
  x = x + 1;
  x = x + 2;
  x = x + 3;
  return x;
}

[HaloFour]

@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.

[IS4Code]

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?

[333fred]

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.

[TahirAhmadov]

@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.)

[TahirAhmadov]

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.

[HaloFour]

I think my biggest concern with pipe-forwarding is that the ecosystem was not designed for it, so one of two things would need to happen. Either a lot of extra syntax would be necessary to glue between the piped operation and the existing APIs, or a new ecosystem of pipe-friendly APIs would be required. Without either (or possibly both to some degree) you end up with having a lot of expressions that ultimately cannot be rewritten entirely into the piped form and you'd frequently run into situations where you have to decompose back into imperative statements.

I also personally don't see that much of a benefit. Sure, you can pack a lot more into what smells like a single expression, but is that really better? In many cases I like having the intermediate assignments to locals, especially since that works a lot better with existing tooling around debugging (which would likely need a bit of work to achieve similar with pipe forwarding to inspect intermediate values). Sure, I have to name those locals, but names are cheap. But I also don't find it at all problematic to have small bits of declarative code within imperative code.

Edit: That's even before we get into the requests for multiple flavors of pipe forwarding, including null propagation and awaiting (and the combination of the two).

[Xyncgas]

You don't need this when you are writing applications that use ASP.NET of .NET Framework on the front end, I've written UI using C# for a long while and I never needed a pipe operator. If you do backend stuff that you might find this useful, but because front-end for windows is 80%+ what c# is for they are not going to invest in doing this. And if you are doing backend, there's C++ and other languages you can use, which let you do stuffs like this

[CyrusNajmabadi]

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

[IS4Code]

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

[FaustVX]

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)

[lawrence-laz]

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.

[viko-stamoff]

Why hasn't this been implemented yet? Such a good idea to have pipes in C#.

[TahirAhmadov]

Not to repeat myself, I posted a comment here about why this code style is problematic.

[iam3yal]

@AlexanderMorou Opinions are great but just because you can't see the problem it solves even though it's well documented in the proposal or you do but wouldn't use it doesn't mean that there isn't one and it's better to counter a fact with a fact rather than opinion, saying that you hope it wouldn't turn into a language feature in my opinion adds nothing useful to the discussion.

[AlexanderMorou]

@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.

[iam3yal]

@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.

[AlexanderMorou]

I really hope this doesn't get turned into a language feature. That may be an unpopular opinion, but most proposals solve a problem.

What problem is this solving?

[CyrusNajmabadi]

@AlexanderMorou the OP seems to outline several cases where this would make things nicer. So the problem it appears to be solving is the clunkyness inherent with existing patterns, replacing them with a more ergonomic form.

You also raised the same point 4 years ago: #96 (comment), and had a similar response back then.

[aloisdg]

Every time you have some write a "fluent" snippet. It could have be better with a pipe operator

[Xyncgas]

Fluent style is pretty interesting, sometimes you can model a domain and be calling methods in this domain, you don't have to worry about what parameter they take when you design it, as long they return the same thing you can 'pipe'/connect them together without compiler complaining. So you are making it pretty on the out side while handling the states inside later, so if you are building something on the top of your head it feels nice and easy when you are doing it this way

[lostmsu]

Relevant discussion of the feature in other languages on Hacker News with some convincing arguments for it.

[lostmsu]

This feature would play nicely with #95 (instance Invoke methods being treated like C++ operator()). Hypothetical example with TorchSharp:

var nn = torch.Input(10)
      |> torch.Linear(256)
      |> torch.Relu()
      |> torch.Linear(256)
      |> torch.Relu()
      |> torch.Linear(1);

[lostmsu]

On disambiguating overloads: I think it would be better to explicitly use a placeholder like !. So you'd do:

"path" |> File.ReadAllBytes // method group

or

"path" |> File.ReadAllLines(!, Encoding.UTF8) // use ! as placeholder like PowerShell's $_

This would also work with members of piped value, and allow multiple accesses:

fileInfo |> File.ReadAllLines(!.FullPath, !.Encoding)

[0x1000000]

The problem with extension methods is that they are not free - lambdas create a fairly large overhead.

However, using an operator as it is done in other functional languages is unlikely to work since C # requires an expression result identifier.

Just another option:
1 + 2 |acc|> acc+3 |acc|> { acc++; return acc + 4; } |acc|> Console.WriteLine(acc.ToString());

using |identifier_name|> instead of just |>

[0x1000000]

It can be even shorter (without the second '|') - just expression|identifier>expression for example:

1+2
|acc> acc+3
|acc> { acc++; return acc + 4; }
|acc> acc.ToString();
|accStr> Console.WriteLine(accStr)
;

Also I'd allow introducing an intermediate variable as follows:

1+2
|var accInitial> accInitial+3
|acc> { acc++; return acc + 4; }
|acc> acc.ToString();
|accStr> Console.WriteLine($"From {accInitial}" to {accStr})
;

The code will be equivalent to this one:

var accInitial = 1+2;
var genVar1 = accInitial +3;
genVar1++;
var genVar2 = genVar1+4;
var genVar3 = genVar2.ToString()
Console.WriteLine($"From {accInitial}" to {genVar3})

[omidkrad]

Here's another example of using extension methods to pipe-forward:

Article: https://dev.to/tomydurazno/pipe-in-c-1aga
Code: https://github.com/TomyDurazno/PipeExtensions

[vbodurov]

Thanks Jacob, I like that, I would just rename underscore to "Then"

[2jacobtan]

I'm doing pipe-forward using extension methods.

static class FunctionChaining
{
    internal static U _<T,U>(this T input, Func<T,U> fun) => fun(input);
    internal static void _<T>(this T input, Action<T> fun) => fun(input);
}

Sample code:
https://gist.github.com/2jacobtan/d410957c6136461090e7d04de2bde314

Edit:

Try at https://dotnetfiddle.net/KvNhXi

Bare-bones blog post at https://medium.com/@jacob.tan.en/c-function-chaining-pipe-forward-using-extension-methods-acbbf497550a

[csharper2010]

Chaining with extension methods does not provide one important benefit of the pipe operator:
The precedence of the pipe operator ist usually very low, the method call "." operator has very high precedence.

Fluent coding doesn't work great because you need to know before writing an expression that you want to call an extension method afterwards because you need to put brackets around the expression. If you forgot those brackets, you have to put the cursor back to before the expression and add the brackets.

The pipe operator can be added after the expression if you decide you want to pipe.

1 + 2 |> Console.WriteLine()

vs.

1 + 2

oh, I want to write it on the console so I need to add the extension method call after and the opening bracket before the expression

(1 + 2)._(Console.WriteLine)

[masaeedu]

To my mind

Console.ReadLine() |> File.ReadAllBytes

always just means:

File.ReadAllBytes(Console.ReadLine())

Console.ReadLine() |> File.ReadAllBytes(new UTF7Encoding()) is an error because there's no overload of ReadAllBytes that takes an Encoding and returns a Func<string, byte[]>. This doesn't have anything to do with the pipeline operator, it's the same error you'd get from trying to do:

File.ReadAllBytes(new UTF7Encoding())(Console.ReadLine())

If we want to deal with a two argument function, we can just do:

Console.ReadLine()
|> (x => File.ReadAllBytes(x, new UTF7Encoding()))

If that's too painful, it can be mitigated at the library level, or with an independent language feature for making partial application more convenient, e.g:

File.ReadAllBytes(?, new UTF7Encoding())
// desugars to
x => File.ReadAllBytes(x, new UTF7Encoding())

[theunrepentantgeek]

It's unambiguous for File.ReadAllBytes right now - in the current version of the framework.

But, what happens if that changes in the future?

For example, and purely for illustration, what if a future version of the framework adds a new overload: File.ReadAllBytes(string, Encoding) ?

The method group would then return two methods, which isn't unique. If the parenthesis were not permitted for the single parameter case, then we'd end up with a disconnect.

For the original overload:

Console.ReadLine()
|> File.ReadAllBytes
|> SHA1.Create().ComputeHash()

But for the new overload:

Console.ReadLine()
|> File.ReadAllBytes(new UTF7Encoding())
|> SHA1.Create().ComputeHash()

I think it's substantially cleaner to require the () to always be there.

Also, and quite separate from my argument above, I suspect that leaving out the () and allowing a method group to be specified would make things ambiguous in some way (though I haven't quite been able to put an example together).

[masaeedu]

Isn't the overload determined by the LHS of the expression? "foo" |> f desugars to f("foo"), which is unambiguous for f = File.ReadAllBytes.

[theunrepentantgeek]

I think it's because simply naming a method (as File.ReadAllBytes) returns a method group - which might include multiple overloaded methods.

Including the () at the end provides a way to specify which overload should be called - in the example, it should call File.ReadAllBytes(string).

[masaeedu]

Sorry if I missed it in the discussion, but why is it:

Console.ReadLine()
|> File.ReadAllBytes()
|> SHA1.Create().ComputeHash()
// ...

instead of the following?

Console.ReadLine()
|> File.ReadAllBytes
|> SHA1.Create().ComputeHash
// ...

Isn't the function here File.ReadAllBytes (and not File.ReadAllBytes())?

[vbodurov]

Can we have pipe aliases? For example:

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

Now I would have ReadBytesAndComputeHash method defined in the class that I can reuse it elsewhere.

The advantage of this is that I achieve 2 goals at the same time:

1. I have the entire pipeline of operations defined in one sequence
2. I can still reuse different parts of it elsewhere

Otherwise it would be impossible to see the entire pipeline with all steps in one place, but at the same time be able to reuse parts of it.

The same could apply for linq:

GetPersons()
:PeoplesNamesStartingWithA
    .Select(p => p.Name)
    .Where(name => name.StartsWith("A"))
:SomeOtherGroup
    .Select....

[IgorX2]

@alrz: It would be cool to be able to pipe tuples as arguments, but the argument order could be a problem.

void F(int a, int b) {}
(arg1, arg2) |> F();     // F(arg1, arg2);

[MorleyDev]

@alrz I read further on the other discussion and saw it talks about this suggestion so deleted my post. Seems you got in there right before, sorry about that :)

Since it's too late and I've been replied to now, I guess I'll sum up what you were replying to: This doesn't look to me like it fits the established expectations and design of the C# language.

The basic pipe operator part of #74 fits closer to what people would closer to what would be intuitive in C# with delegation, whilst this RHS proposal currently requires a mental context-switch from "normal overload resolution" to "pipe papp", where how you would by-default mentally parse the syntax is incorrect. This...seems problematic.

If a form of currying gets added in the future it would behave similar to the above does, and an intermediate lambda solves so much of the issue in the short-term that it is what I'd expect that for an initial implementation into C#, leaving room for currying/papp later without committing to any particular syntax.

(Interestingly, I've seen the usage of an intermediate lambda cited as a reason for a lack of motivation in introducing currying to ECMAScript nowadays as well).

[alrz]

@MorleyDev

Here I suggested to just "add the LHS as an argument to the method invocation on the right." (other than some cases with optional arguments which can be excluded if seen as rather unreliable than helpful). that doesn't require you to fallback to lambda when there is more than a single parameter (which I've found very likely). There's a discussion on the other variation here: #74

[AlexanderMorou]

@alrz : The biggest gripe I have with the feature is the disconnect between what you're writing and where the data actually goes. The notion that it would bind differently based on the type of the parameter: overload resolution is already complicated enough as it is, if there was some way to explicitly stipulate which parameter was the target of the forwarded pipe, through say a special character combination of some sort:

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

This way if it were targeting a specific parameter, the notion of overload resolution wouldn't be a concern, if you wanted parameter z of type U to be the target, and optional parameters were in play, you could simply go: A() |> B(z:<|);

That would make the binding of the operation much simpler to understand, and I think the reader would benefit, as well.

What syntax are you imagining for that as a separate feature?

Probably something like: ?? prefixing the argument
?? alone would probably be sufficient because it is evident that it's not a nullable coalescing operator as there's only one operand.

As for weaving it into the language spec as it is today, it would probably be something like:

argument_value
    : '??'? expression
    | '??'? '<|'
    | 'ref' '??'? variable_reference
    | 'out' variable_reference
    ;

It wouldn't be allowed on the out parameter because it's implicitly unassigned within the scope of the called method, so it wouldn't really make sense.

The default value of the method would be the result of the expression if it short-circuited.

If you were to take the two ideas together, you would only need one pipe-forward operator: |>, the ?> would be replaced by: ?? <| on the parameter you intended it to be for. So instead of:

if (args != null)
{
   format
   ?> String.Format(args: args)
   ?> Console.WriteLine();
}

You'd end up with:

String.Format(?? format, ?? args)
|> Console.WriteLine(?? <|);

[alrz]

but it doesn't make the code any shorter.

that's not the intention here.

And it's just as easy to read

It's not as easy to write since you should be writing the methods in the reverse order. Using locals however, can help with that but then you have to leave the expression context.

The only thing I do like is the argument-level short-circuiting, though that sounds like it could be a feature request of its own for standard calling conventions.

What syntax are you imagining for that as a separate feature?

[AlexanderMorou]

I don't understand what actual problem this solves.

Sure, it unwraps the call chain so it places the methods in their actual execution order, but it doesn't make the code any shorter. There are few (if any?) cases I've encountered where I couldn't follow nested parameters. You could turn the example into:

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

And it's just as easy to read, as the parenthesis make the execution order clear. It's also crystal clear, within which parameter an argument will actually be placed, without worrying about implicit conversions coercing the actual parameter you're specifying.

What implications does this have for IntelliSense, would it provide context on what parameter it goes into by hovering over the |> characters? Wouldn't you also have to ensure the right-hand side of the operator, within the intellisense that it's accepting one forwarded operator in some manner?

The only thing I do like is the argument-level short-circuiting, though that sounds like it could be a feature request of its own for standard calling conventions.

[slaymaker1907]

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.

[alrz]

@a1n1 Not sure, but supposedly, there will be a "champion" issue once this passes the first stage.

@chrisaut This has the input parameter added to the argument list. That proposal requires there be no argument list i.e. the LHS would be forwarded to the "value" of the RHS, hence, it would not permit forwarding to methods with more than a single (formal) parameter and you'd need to use @ syntax.

[chrisaut]

What's the difference between this and #74 ?

[a1n1]

Is this issue acceptable for pull request ?