# \[ANN\] JET.jl: the next generation of code checker for Julia

**URL:** <https://discourse.julialang.org/t/ann-jet-jl-the-next-generation-of-code-checker-for-julia/58913>\
**Category:** Package Announcements\
**Tags:** inference, type-stability\
**Created:** [April 9, 2021, 11:11am UTC](https://discourse.julialang.org/t/ann-jet-jl-the-next-generation-of-code-checker-for-julia/58913 "2021-04-09T11:11:47Z")\
**Posts on this page:** 1\
**Showing post:** 10

<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:** [April 20, 2021, 8:34pm UTC](https://discourse.julialang.org/t/ann-jet-jl-the-next-generation-of-code-checker-for-julia/58913/10 "2021-04-20T20:34:07Z")

</div>

I believe that is by design. The space of possible julia types is truly gigantic. For generic functions, there are formally an infinite number of possible type signatures due to parametric types.

JET could of course special case concrete methods like the one you show, but in general, the only sane way to handle arbitrary julia code is to investigate signatures that can possibly be called.

---

_[View the full topic](https://discourse.julialang.org/t/ann-jet-jl-the-next-generation-of-code-checker-for-julia/58913)._