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

<div class="post-metadata">

**Author:** ![chakravala](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chakravala/32/6832_2.png) [@chakravala](https://discourse.julialang.org/u/chakravala)\
**Post date:** [April 30, 2018, 9:56am UTC](https://discourse.julialang.org/t/possibility-of-local-import-statements-in-future/10611/11 "2018-04-30T09:56:18Z")

</div>

Yea, tried it. Like I said, I suppose it could do, but it is not properly extending the function and it cannot be imported en masse for a large number of functions without having to evaluate many more assignments.

```nohighlight
module Foo
    export +
    +(a,b) = Base.:+(a,b)
    +(a::Symbol, b::Symbol) = 2
end

julia> importall Foo
WARNING: ignoring conflicting import of Foo.+ into Main

```

Instead, the user has to be asked to do `+ = Foo.:+` for every single function. Theoretically, one could create a function that generates the code to do all those assignments for you, but the user would still have to enter something like `eval(Foo.generated_assignments())`, and evaluated in the `Main` scope.

```nohighlight
julia> module Foo
           export +
           +(a,b) = Base.:+(a,b)
           +(a::Symbol, b::Symbol) = 2
           generated_assignments() = :(+ = Foo.:+)
       end
Foo

julia> :x+:y
ERROR: MethodError: no method matching +(::Symbol, ::Symbol)

julia> eval(Foo.generated_assignments())
WARNING: imported binding for + overwritten in module Main
+ (generic function with 2 methods)

julia> :x+:y
2

```

It would be preferable if the language itself could handle this properly.

Specifically, instead of ignoring conflicting imports, it could replace them instead. Then this would change how everything works slightly, but would be more flexible perhaps. Or a new keyword should exist so that the imports can be forced to overwrite the existing function, like `local import Foo`, but with the same effect as having `eval(Foo.generated_assignments())`. That should’nt be too difficult to add to Julia, right?

People said it was impossible, but here we are. Looks like a `local import` can happen, it only needs to be part of the language now.

---

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