# 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:** 56

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [May 2, 2018, 11:09am UTC](https://discourse.julialang.org/t/possibility-of-local-import-statements-in-future/10611/56 "2018-05-02T11:09:10Z")

</div>

> [@TsurHerman](#):
>
> in a way that is not so breakable.

Can you please clarify which feature of the language you have a problem with? The ability to write methods

1. for **functions** defined in another module,
2. for **functions and types** defined in other modules (not necessarily the same),
3. for **functions and types, all defined in the same module** ,
4. that **overwrite existing methods** , defined in another module?

Guidelines about [type piracy](https://docs.julialang.org/en/latest/manual/style-guide/#Avoid-type-piracy-1) are not formally enforced by the language, but catch (2) and (3), and also (4) if the other definition that would be overwritten avoids type piracy. OTOH, restricting (1) would kill a very useful feature.

---

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