# Multiple dispatch unexpected function call

**URL:** <https://discourse.julialang.org/t/multiple-dispatch-unexpected-function-call/78736>\
**Category:** General Usage\
**Tags:** question\
**Created:** [March 30, 2022, 12:14pm UTC](https://discourse.julialang.org/t/multiple-dispatch-unexpected-function-call/78736 "2022-03-30T12:14:23Z")\
**Posts on this page:** 1\
**Showing post:** 9

<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:** [March 30, 2022, 5:41pm UTC](https://discourse.julialang.org/t/multiple-dispatch-unexpected-function-call/78736/9 "2022-03-30T17:41:42Z")

</div>

Here’s what I find surprising about this behaviour that I’m surprised hasn’t been focused on more: `f(c1::Concrete{T}, c2::Concrete{T}) where T` is applicable to only a **diagonal** subset of types.

E.g. if we have `N` possible type parameters, then

```julia
f(c1::Concrete, c2::Concrete)

```

could have `N^2` possible specializations, whereas

```julia
f(c1::Concrete{T}, c2::Concrete{T}) where T

```

only has `N` possible specializations because it requires that the parameters match. To me, this means that this method is strictly more specific and hence should be prioritized by dispatch.

---

_[View the full topic](https://discourse.julialang.org/t/multiple-dispatch-unexpected-function-call/78736)._