# Improvement for function chaining operator
**URL:** https://discourse.julialang.org/t/improvement-for-function-chaining-operator/38283
**Category:** Internals & Design
**Created:** [April 27, 2020, 5:03am UTC](https://discourse.julialang.org/t/improvement-for-function-chaining-operator/38283 "2020-04-27T05:03:55Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@govorunov](https://discourse.julialang.org/u/govorunov)
#### Post date: [April 27, 2020, 5:03am UTC](https://discourse.julialang.org/t/improvement-for-function-chaining-operator/38283/1 "2020-04-27T05:03:55Z")
Dear Julia founders and maintainers, please consider changing the function chaining (piping) operator to accept call specifications. The new syntax, as I see it would look like:
```
var >. callable(opt_param1, opt_param2)
```
and would mean precisely "take whatever on the left side of the operator and pass it as the first parameter to the callable on the right side, along with other optional parameters provided in the call.
Yes, this will essentially introduce “abominable” object-oriented syntax in Julia. Please don’t start lecturing me about the merits of multiple dispatch - I know and agree. The thing is I love Julia. I love Julia that much that I hope one day it will overtake Python, Java, and other high-level programming languages, but to achieve this Julia has to become more user and beginner-friendly. The syntax like `var.func1(param1, param2).func2(param3, param4) ` is extremely ubiquitous in programming and I believe one of the key things that made object-oriented programming so popular.
I propose syntax `>.` for this new piping operator because it is much easier to type than `|>` and it is currently available. Not only it will make Julia immediately more appealing to millions of object-oriented developers and beginners (without losing a bit of its current features) this will also make possible implementing proper autocompletion in Julia editors. Developers use autocompletion because it helps navigate things that you can potentially do next, not because it corrects spelling. If this operator was made part of language syntax, editors would be able to list all functions that potentially accept “type on the left” as the first argument whenever somebody types `>.`
I am not asking for a macro hack that will make some resemblance of such operator possible in the current syntax. I am asking to consider adding this operator in some future versions of Julia language.
And thank you very much for your incredible work! You are my heroes!
---
### Author:  [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)
#### Post date: [April 27, 2020, 5:34am UTC](https://discourse.julialang.org/t/improvement-for-function-chaining-operator/38283/2 "2020-04-27T05:34:21Z")
The reason this won’t happen is it would seriously conflict with the . Syntax for vectorization.
---
### Author:  [@Syx\_Pek](https://discourse.julialang.org/u/Syx_Pek)
#### Post date: [April 27, 2020, 5:45am UTC](https://discourse.julialang.org/t/improvement-for-function-chaining-operator/38283/3 "2020-04-27T05:45:39Z")
Someday when we agree of how [#24990](https://github.com/JuliaLang/julia/pull/24990) should work and we can write the fairly neat
`var |> callable(_, opt_param1, opt_param2)`
Edit: I don’t see why `|>` instead of `>.` makes much difference. Also, why not a “macro hack”?
---
### Author:  [@govorunov](https://discourse.julialang.org/u/govorunov)
#### Post date: [April 27, 2020, 5:45am UTC](https://discourse.julialang.org/t/improvement-for-function-chaining-operator/38283/4 "2020-04-27T05:45:58Z")
Sorry, I don’t see how.
The vectorisation syntax:
```
callable.(var, param1, param2)
```
The proposed syntax with vectorisation:
```
var >. callable.(param1, param2)
```
Really the `>.` syntax does not seem to appear anywhere now.
If passing left argument as first parameter inflicts aversion, it is possible to optionally use placeholder parameter (underscore) to indicate place where the left argument should go:
```
var >. callable(_, param1, param2)
```
However the first syntax is more readable both are actually acceptable.
---
### Author:  [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)
#### Post date: [April 27, 2020, 5:50am UTC](https://discourse.julialang.org/t/improvement-for-function-chaining-operator/38283/5 "2020-04-27T05:50:50Z")
How would it interact with functions like + that are infix?
---
### Author:  [@govorunov](https://discourse.julialang.org/u/govorunov)
#### Post date: [April 27, 2020, 5:59am UTC](https://discourse.julialang.org/t/improvement-for-function-chaining-operator/38283/6 "2020-04-27T05:59:50Z")
This looks promising! Thank you!
`>.` is 10 times easier to type than `|>` Just try it. And consider, when implemented, this operator will be used quite often.
As for ‘not macro’, for once I’m not asking for a solution for myself, I hope to make the language more appealing to beginners so it will become more popular. It has to be generally accepted syntax and not just some hack for the knowing.
For the same reason I’d vote for inclusion of [SimpleTraits.jl](https://github.com/mauro3/SimpleTraits.jl) into the core library and making it standard for implementing interfaces. Having something officially supported and having it as some module with the hack that you can find online is not the same.
---
### Author:  [@govorunov](https://discourse.julialang.org/u/govorunov)
#### Post date: [April 27, 2020, 6:04am UTC](https://discourse.julialang.org/t/improvement-for-function-chaining-operator/38283/7 "2020-04-27T06:04:46Z")
> [@Oscar\_Smith](#):
>
> How would it interact with functions like + that are infix?
Well, obviously `a + b` equals to `a >. +(b)`, or `a >. +(_, b)` with placeholder syntax. However I don’t see why anyone would use this syntax, to begin with.