# Constructors for \`\<:Function\` types when possible, like in C++

**URL:** <https://discourse.julialang.org/t/constructors-for-function-types-when-possible-like-in-c/86611>\
**Category:** Internals & Design\
**Tags:** inference, function, constructors\
**Created:** [August 31, 2022, 6:19pm UTC](https://discourse.julialang.org/t/constructors-for-function-types-when-possible-like-in-c/86611 "2022-08-31T18:19:58Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![Mason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mason/32/2423_2.png) [@Mason](https://discourse.julialang.org/u/Mason)\
**Post date:** [August 31, 2022, 7:26pm UTC](https://discourse.julialang.org/t/constructors-for-function-types-when-possible-like-in-c/86611/2 "2022-08-31T19:26:57Z")

</div>

Every ‘singleton’ struct can be constructed from it’s type using `T.instance`

```julia-auto
julia> struct Foo end

julia> Foo.instance
Foo()

julia> typeof(sqrt).instance
sqrt (generic function with 19 methods)

julia> typeof(+).instance
+ (generic function with 206 methods)

```

I doubt this provides any great opportunities for optimizations though, and it’s generally not a good idea.

This sort

> [@nsajko](#):
>
> Still, even after realizing that functions are singleton types I thought that there might be a certain reason to prefer passing functions as types: the [Performance of captured variables](https://docs.julialang.org/en/v1/manual/performance-tips/#man-performance-captured) issue. I thought that passing functions as types could enable writing more concise code with closures, because `let` isn’t necessary for type parameters. Long story short, turns out that `let` is _also_ unnecessary for variables that happen to be of singleton type.

I think you should read that section again. The boxing problem only comes into play if you rebind the captured variable.

---

_[View the full topic](https://discourse.julialang.org/t/constructors-for-function-types-when-possible-like-in-c/86611)._