# Function name conflict: ADL / function merging?

**URL:** <https://discourse.julialang.org/t/function-name-conflict-adl-function-merging/10335>\
**Category:** Internals & Design\
**Tags:** proposal, namespaces\
**Created:** [April 14, 2018, 5:16pm UTC](https://discourse.julialang.org/t/function-name-conflict-adl-function-merging/10335 "2018-04-14T17:16:17Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![ssfrr](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ssfrr/32/3736_2.png) [@ssfrr](https://discourse.julialang.org/u/ssfrr)\
**Post date:** [April 15, 2018, 2:27am UTC](https://discourse.julialang.org/t/function-name-conflict-adl-function-merging/10335/7 "2018-04-15T02:27:33Z")

</div>

> [@tk3369](#):
>
> IMHO, defining a function with my own types (hence not a type piracy problem) that happens to have the same name as an exported function from a dependent package should still be allowed. There’s no ambiguity.

I agree that it wouldn’t be a type piracy issue if Julia let you define your own `stack` function in this way (which would be separate from the `stack` function exported by the dependent package), so then locally the identifier `stack` would point to your function rather than the existing one.

The trade-off is that if you actually _did_ intend to extend the existing `stack`, things are broken in a subtle and confusing way. I don’t have any data on this, but my hunch is that extending functions is far more common than defining new functions with the same name as an existing one. I’m guessing this error is thrown to prevent that situation.

Note this is also an argument for `using Foo: bar, baz` to be explicit about what names you pull into your local namespace, so if you did want to define your own `stack` function, you wouldn’t `using` it.

---

_[View the full topic](https://discourse.julialang.org/t/function-name-conflict-adl-function-merging/10335)._