# Function inside struct allocates when referenced

**URL:** <https://discourse.julialang.org/t/function-inside-struct-allocates-when-referenced/105785>\
**Category:** New to Julia\
**Tags:** function\
**Created:** [November 4, 2023, 4:55am UTC](https://discourse.julialang.org/t/function-inside-struct-allocates-when-referenced/105785 "2023-11-04T04:55:37Z")\
**Posts on this page:** 1\
**Showing post:** 19

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [November 7, 2023, 1:58am UTC](https://discourse.julialang.org/t/function-inside-struct-allocates-when-referenced/105785/19 "2023-11-07T01:58:54Z")

</div>

> [@izod2](#):
>
> Can you comment on what “giving them all the same type” means?

> [@nsajko](#):
>
> Does not hold for closures, they don’t have to be singleton types:

By default, a function is an instance of a singleton type, meaning that type only has 1 instance, the function itself. However, that is not necessarily the case; if a function were to contain data from a local scope, then it would not have a singleton type. The non-singleton function factory example nsajko provided is a bit indirect, it’d be clearer to write out the underlying [functors](https://docs.julialang.org/en/v1/manual/methods/#Function-like-objects) with a type that subtypes `Function`, making them functions. There would still only be 1 method table associated with the functors’ type, but the functors would act differently because of the data they contain. Of course, this still restricts the functors to do almost the same thing, so it might not be applicable to your use case. FunctionWrappers.jl lets the multiple input functions have different method tables and types as a tradeoff for attaching a call signature restriction. (Normally, a function has multiple methods, and each method can be compiled for multiple call signatures; a call is dispatched to a method based on the function’s type as well as the arguments’ types).

To expand on the explicitness, unlike writing out a functor type to contain data in manually annotated fields, closures handle it implicitly so it’s not visible in one place:

```julia-auto
julia> f(n, m) = let n = n, m = m
         foo(x) = x+n # 1st method captures n
         # maybe a lot of other code
         foo() = m # 2nd method captures m
       end
f (generic function with 1 method)

julia> f(1, 1.0) # type parameters means function contains both n and m
(::var"#foo#1"{Int64, Float64}) (generic function with 2 methods)

```

Instantiating functors also don’t have to deal with variable scoping rules; closures are local scopes that technically capture _variables_, not data at instantiation, and any reassignment prevents the compiler from [inferring the variable’s type well](https://discourse.julialang.org/t/can-someone-explain-closures-to-me/105605/2), even if [unnecessary and accidental](https://discourse.julialang.org/t/pinv-not-type-stable/103885/10).

---

_[View the full topic](https://discourse.julialang.org/t/function-inside-struct-allocates-when-referenced/105785)._