# Fixing the Piping/Chaining Issue

**URL:** <https://discourse.julialang.org/t/fixing-the-piping-chaining-issue/89654>\
**Category:** Internals & Design\
**Tags:** proposal, piping, chaining, partial-evaluation, threading\
**Created:** [November 2, 2022, 11:04am UTC](https://discourse.julialang.org/t/fixing-the-piping-chaining-issue/89654 "2022-11-02T11:04:36Z")\
**Posts on this page:** 1\
**Showing post:** 198

<div class="post-metadata">

**Author:** ![uniment](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/uniment/32/24532_2.png) [@uniment](https://discourse.julialang.org/u/uniment)\
**Post date:** [November 10, 2022, 4:51pm UTC](https://discourse.julialang.org/t/fixing-the-piping-chaining-issue/89654/198 "2022-11-10T16:51:32Z")

</div>

> [@Sukera](#):
>
> that the core problem can be solved without new syntax (as you’ve shown, by implementing a rudimentary autocomplete yourself).

My point was that the actual core problem was one of _motivation_: people need a _reason_ to work on an autocomplete, hopefully beyond just being an academic pursuit. Which syntax sugar provides. In the same way, somebody was motivated to write an autocomplete for `.` but not `getproperty`, despite the former being just sugar for the latter, in the confidence that the autocomplete on `.` would find heavy use and the effort would not go to waste.

> [@Sukera](#):
>
> That is a requirement that hasn’t changed, as your code literally has `typeof(obj)` in it, which is not necessarily something an editor can do because the editor would potentially have to run your code to figure that out, which you surely don’t want (or run type inference on all of your code, which runs into the problem of “partial inference is not implemented”).

With sufficient motivation, somebody smarter than me will figure this out I’m sure. In the meantime, I’d be pretty happy to have autocomplete in REPL mode.

---

_[View the full topic](https://discourse.julialang.org/t/fixing-the-piping-chaining-issue/89654)._