# Error with modules sharing types

**URL:** <https://discourse.julialang.org/t/error-with-modules-sharing-types/37119>\
**Category:** New to Julia\
**Created:** [April 6, 2020, 5:03pm UTC](https://discourse.julialang.org/t/error-with-modules-sharing-types/37119 "2020-04-06T17:03:06Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![peterj](https://avatars.discourse-cdn.com/v4/letter/p/22d042/32.png) [@peterj](https://discourse.julialang.org/u/peterj)\
**Post date:** [April 6, 2020, 5:03pm UTC](https://discourse.julialang.org/t/error-with-modules-sharing-types/37119/1 "2020-04-06T17:03:06Z")

</div>

The following code gives me an error with Julia v1.4

```julia
# M1.jl
module M1
    export M1Type
    struct M1Type
        data::Real
    end
end

# M2.jl
module M2
    using ..M1
    export f
    function f(x::M1Type)
        
    end
end

# At the REPL (or main module)
using .M1
using .M2
f(M1Type(1))

```

and the error is

```julia
 MethodError: no method matching f(::M1Type) Closest candidates are: f(::Main.M1.M1Type) Stacktrace:..

```

Currently the workaround I use is to have the main module only have `using .M1`, and use `Reexport.jl` to reexport everything in M1 from M2, but I shouldn’t need to do that, right?

---

<div class="post-metadata">

**Author:** ![rdeits](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rdeits/32/286_2.png) [@rdeits](https://discourse.julialang.org/u/rdeits)\
**Post date:** [April 6, 2020, 6:47pm UTC](https://discourse.julialang.org/t/error-with-modules-sharing-types/37119/2 "2020-04-06T18:47:50Z")

</div>

Pasting exactly the code you provided into the REPL works as expected:

```julia
julia> # M1.jl
       module M1
           export M1Type
           struct M1Type
               data::Real
           end
       end
Main.M1

julia> # M2.jl
       module M2
           using ..M1
           export f
           function f(x::M1Type)
               
           end
       end
Main.M2

julia> # At the REPL (or main module)
       using .M1

julia> using .M2

julia> f(M1Type(1))

julia> 

```

so the problem has something to do with how you are actually including your files. The results you’re seeing are consistent with having called `include()` on the same file in multiple different modules, which you not ever do (see [Organizing modules. Is it OK to organize a project using several modules in Julia? - #5 by rdeits](https://discourse.julialang.org/t/organizing-modules-is-it-ok-to-organize-a-project-using-several-modules-in-julia/34535/5) , [Organizing structs and modules - #3 by rdeits](https://discourse.julialang.org/t/organizing-structs-and-modules/34993/3) , etc). Can you be more explicit about how you’ve actually set up your code to run into the problem you’re seeing?

---

<div class="post-metadata">

**Author:** ![peterj](https://avatars.discourse-cdn.com/v4/letter/p/22d042/32.png) [@peterj](https://discourse.julialang.org/u/peterj)\
**Post date:** [April 6, 2020, 7:01pm UTC](https://discourse.julialang.org/t/error-with-modules-sharing-types/37119/3 "2020-04-06T19:01:59Z")

</div>

Huh I just tried it again and it worked fine. Weird, sorry about that.

> The results you’re seeing are consistent with having called include() on the same file in multiple different modules, which you not ever do

Yes, that’s exactly what I was doing. More precisely, this replicates the error:

(each section in its own file this time)

```julia
# module_1.jl
module M1
    export M1Type
    struct M1Type
        data::Real
    end
end

```

```julia
# module_2.jl
module M2
    include("module_1.jl")
    using .M1
    export f
    function f(x::M1Type)
        
    end
end

```

```julia
#main.jl
include("module_1.jl")
include("module_2.jl")
using .M1
using .M2
f(M1Type(1))

```

If I don’t use the `include` statements in this way, the compiler complains about not being able to recognize certain functions/types. From what I’ve read, I could organize them into their own projects, and import them by modifying `LOAD_PATH`, but is that the only way to have local modules? It seems unnecessarily complex.

---

<div class="post-metadata">

**Author:** ![rdeits](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rdeits/32/286_2.png) [@rdeits](https://discourse.julialang.org/u/rdeits)\
**Post date:** [April 6, 2020, 7:12pm UTC](https://discourse.julialang.org/t/error-with-modules-sharing-types/37119/4 "2020-04-06T19:12:41Z")

</div>

Yeah, you definitely don’t want to do that–you are creating two completely unrelated modules called `M1` by calling `include()` twice. If you’re familiar with C++, this would be like including the same header outside of _and_ inside of a namespace.

You don’t need to use projects for this (although projects are incredibly useful). Just add the current directory (“.”) to your `LOAD_PATH` and get rid of all your `include()` calls:

```julia
julia> push!(LOAD_PATH, ".")
4-element Array{String,1}:
 "@"
 "@v#.#"
 "@stdlib"
 "."

julia> using M1
[Info: Precompiling M1 [top-level]

```

---

<div class="post-metadata">

**Author:** ![Vasily\_Pisarev](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vasily_pisarev/32/7929_2.png) [@Vasily\_Pisarev](https://discourse.julialang.org/u/Vasily_Pisarev)\
**Post date:** [April 6, 2020, 11:19pm UTC](https://discourse.julialang.org/t/error-with-modules-sharing-types/37119/5 "2020-04-06T23:19:52Z")

</div>

As a side note: the definition

```julia
struct MyType
    data::Real
end

```

is generally discouraged in favor of

```julia
struct MyType{T<:Real}
    data::T
end

```

([Performance Tips · The Julia Language](https://docs.julialang.org/en/v1/manual/performance-tips/#Avoid-fields-with-abstract-type-1))  
As far as I know, there is no reason at all to declare abstract types for immutable struct fields: since an immutable struct’s data fields cannot be changed, binding the value to a concrete type at construction incurs no restriction. There might only be a reason to do that for mutable types, where you might indeed need to change the data in object during its lifetime.