# Possibility of \`local import\` statements in future?

**URL:** <https://discourse.julialang.org/t/possibility-of-local-import-statements-in-future/10611>\
**Category:** Internals & Design\
**Tags:** scope\
**Created:** [April 29, 2018, 8:41pm UTC](https://discourse.julialang.org/t/possibility-of-local-import-statements-in-future/10611 "2018-04-29T20:41:39Z")\
**Posts on this page:** 1\
**Showing post:** 29

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [April 30, 2018, 3:33pm UTC](https://discourse.julialang.org/t/possibility-of-local-import-statements-in-future/10611/29 "2018-04-30T15:33:56Z")

</div>

> [@chakravala](#):
>
> Anyway, it’s not like you are the single person responsible for that decision.

No, but various proposals for forced/automatic resolution of import conflicts have been discussed extensively and repeatedly (see e.g. [Function name conflict: ADL / function merging? - #38 by kristoffer.carlsson](https://discourse.julialang.org/t/function-name-conflict-adl-function-merging/10335/38) for a recent example) and most of the core developers seem to be generally opposed to anything in Base that promotes silent overwriting of symbols without explicitly enumerating them. You can certainly submit a PR to `julia`, of course, but I personally doubt it will get much traction.

---

_[View the full topic](https://discourse.julialang.org/t/possibility-of-local-import-statements-in-future/10611)._