Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Enhanced Forward Pipe Operator #8670

Closed
vbcodec opened this issue Feb 13, 2016 · 6 comments
Closed

Proposal: Enhanced Forward Pipe Operator #8670

vbcodec opened this issue Feb 13, 2016 · 6 comments

Comments

@vbcodec
Copy link

vbcodec commented Feb 13, 2016

Proposal #5445 (Forward Pipe Operator) is good idea, but incomplete. The value returned from previous function call is anonymous, which make impossible to express scenarios like:

Print (iif(GetPoint().Y <= 10, "Below min.", "Above min"))
Print (Serialize(GetRectangle()).ToHash())
MakeRectangle (GetPoint(), other_point)

The solution is to introduce keyword PV (Previous Value), which represent value returned from previous call. This keyword is local, available only fo functions inside pipe. With this keyword, these examples can be implemented as:

GetPoint()
|> Print (iif(PV.Y <= 10, "Below min.", "Above min"))

GetRectangle()
|> Serialize(PV).ToHash()
|> Print()
' OR
GetRectangle()
|> Serialize() ' here PV is rectangle
|> PV.ToHash() ' here PV is string
|> Print()

GetPoint ()
|> MakeRectangle (PV, other_point)

Other options is to auto create local variables, PV1, PV2, and so on, that represent returned values from each call. With these variables it is possible to use values more than once, for example:

GetPoint() ' PV1
|> GetPoint () ' PV2
|> MakeRectangle (PV1, PV2) ' PV and PV3
|> Print ("Rectangle (P1: " & PV1.ToString() & ", P2: " & PV2.ToString() & ") have area " & PV.Area)

New keyword and variables greatly generalize proposal #5445

@alrz
Copy link
Member

alrz commented Feb 13, 2016

The point is to apply the function in a postfix manner, so

GetRectangle()
|> Serialize()

would be enough.

@HaloFour
Copy link

The result is supposed to be anonymous as it is supposed to be automatically applied to the target function. If you need to use the result directly then you can just declare a variable. Using some arbitrary sigil would just be confusing, and your proposed keyword is not intuitive and doesn't follow the convention of any other keyword in the language. Indexed sigils would be even worse due to introducing a feature that is very brittle to refactoring.

@vbcodec
Copy link
Author

vbcodec commented Feb 13, 2016

@alrz
thanks, corrected

@HaloFour
My proposal is compatible with #5445, and anonymous (unavailable) values still can be used. New keyword and variables are optional, and may be used where necessary. External variables aren't good, because they decompose pipe into smaller pieces.. As for naming, PV may be replaced with #, $ or something more intuitive.

@alrz
Copy link
Member

alrz commented Feb 13, 2016

In that case, this is a duplicate of #3171

@smoothdeveloper
Copy link

@vbcodec it seems that what you want to achieve with PV is doable with anonymous functions (using C# notation because I'm unsure of VB notation outside of IDE).

GetRectangle()
|> (pv) => Serialize(pv).ToHash()
|> Print()

If pipe operator is sought after, it is highly common to have top level functions, for exemple you'd have a hash function instead of calling .ToHash, going functional first you end up with code like this:

GetRectangle()
|> serialize
|> hash
|> print

@gafter
Copy link
Member

gafter commented Mar 24, 2017

We are now taking language feature discussion in other repositories:

Features that are under active design or development, or which are "championed" by someone on the language design team, have already been moved either as issues or as checked-in design documents. For example, the proposal in this repo "Proposal: Partial interface implementation a.k.a. Traits" (issue 16139 and a few other issues that request the same thing) are now tracked by the language team at issue 52 in https://github.com/dotnet/csharplang/issues, and there is a draft spec at https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md and further discussion at issue 288 in https://github.com/dotnet/csharplang/issues. Prototyping of the compiler portion of language features is still tracked here; see, for example, https://github.com/dotnet/roslyn/tree/features/DefaultInterfaceImplementation and issue 17952.

In order to facilitate that transition, we have started closing language design discussions from the roslyn repo with a note briefly explaining why. When we are aware of an existing discussion for the feature already in the new repo, we are adding a link to that. But we're not adding new issues to the new repos for existing discussions in this repo that the language design team does not currently envision taking on. Our intent is to eventually close the language design issues in the Roslyn repo and encourage discussion in one of the new repos instead.

Our intent is not to shut down discussion on language design - you can still continue discussion on the closed issues if you want - but rather we would like to encourage people to move discussion to where we are more likely to be paying attention (the new repo), or to abandon discussions that are no longer of interest to you.

If you happen to notice that one of the closed issues has a relevant issue in the new repo, and we have not added a link to the new issue, we would appreciate you providing a link from the old to the new discussion. That way people who are still interested in the discussion can start paying attention to the new issue.

Also, we'd welcome any ideas you might have on how we could better manage the transition. Comments and discussion about closing and/or moving issues should be directed to #18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.

I recommend conversation on this feature request continue either at dotnet/csharplang#96 or dotnet/csharplang#74.

@gafter gafter closed this as completed Mar 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants