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

<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 26, 2019, 5:31pm UTC](https://discourse.julialang.org/t/proposal-for-sharedfunctions-jl-package-for-optional-dependency-management/23526/31 "2019-04-26T17:31:51Z")

</div>

> [@kristoffer.carlsson](#):
>
> The reason why we cannot just merge the two `f` is because of how you write generic code.

How about this rule to solve this:

Only import a name from a `SharedFunctions` package if you don’t intend to write generic method with only the `Any` type dispatch; otherwise have the generic definitions in `SharedFunctions`

Shared function names with completely generic method definitions should either

1. have the generic definitions in the `SharedFunctions` package
2. not be imported from `SharedFunctions`

This way, if there is a need for generic methods, the fully generic method is either shared by all who import `SharedFunctions` or the entire method name needs a new namespace, in case of a “generic method conflict.”

This also makes it easy, if you later decide to add a generic method, you can either drop the import statement (and define locally) or contribute the generic definition to `SharedFunctions`.

---

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