# Proposal for SharedFunctions.jl package for optional dependency management

**URL:** <https://discourse.julialang.org/t/proposal-for-sharedfunctions-jl-package-for-optional-dependency-management/23526>\
**Category:** Internals & Design\
**Created:** [April 25, 2019, 5:18pm UTC](https://discourse.julialang.org/t/proposal-for-sharedfunctions-jl-package-for-optional-dependency-management/23526 "2019-04-25T17:18:42Z")\
**Posts on this page:** 1\
**Showing post:** 28

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [April 26, 2019, 1:03pm UTC](https://discourse.julialang.org/t/proposal-for-sharedfunctions-jl-package-for-optional-dependency-management/23526/28 "2019-04-26T13:03:38Z")

</div>

> [@lobingera](#):
>
> What is your definition of generic function? If i look into the manual i find in [Julia Functions · The Julia Language](https://docs.julialang.org/en/v1/devdocs/functions/#Method-Tables-1) starting with the sentence “Every function in Julia is a generic function.”

This is true although I am not sure how to be more clear. A different generic function with the same name is a function with the same name as another function… For example:

```julia
module A
f(x) = x
end

module B
f(x, y) = x + y
end

```

Here `A.f` and `B.f` are different (generic) functions.

The reason why we cannot just merge the two `f` is because of how you write generic code. An example of a generic function is `push!`. We can see the docs for it:

```julia
  push!(collection, items...) -> collection

  Insert one or more items at the end of collection.

```

We now know what the generic function `Base.push!` means. We can extend that function to our own types by adding a method to `Base.push!`. Everyone who extends this function agrees that they are using the documented meaning of `push!`. We can now make a generic function that takes a collection and uses the function `Base.push!` somewhere in the function body, on that collection.

Now, let’s consider another function with the same name:

```julia
module MyGame

"""
    push!(p)
Push the person `p` to an adjacent square
"""
function push!(p) end

end

```

This has a completely different meaning than `Base.push!`. This is fine though because in generic code we either use `Base.push!` or `MyGame.push!`. These are different functions so we need the concept of namespaces to decide which one to use.

Now, if `Base.push!` and `MyGame.push!` was merged, it is impossible to look at a piece of generic code that uses `push!` and figure out what it is doing. Is it adding things to a collection or pushing person’s around? As already been said, all functions are generic, so without a way to know what the generic functions do, it is impossible to reason about generic code. Any function could mean anything.

Therefore, with regards to the proposed SharedFunctions, it can either be that

1. The first one to claim a function name gets to document it. We then know what that function does and can write generic code with it.
2. Everyone extends the function with the same name with no regards of what the function means. It is then not possible to write generic code with that function (because the concept of the meaning of a function doesn’t exist anymore).

---

_[View the full topic](https://discourse.julialang.org/t/proposal-for-sharedfunctions-jl-package-for-optional-dependency-management/23526)._