# Concrete vs parametric when determining type specificity

**URL:** <https://discourse.julialang.org/t/concrete-vs-parametric-when-determining-type-specificity/104784>\
**Category:** General Usage\
**Created:** [October 10, 2023, 4:09am UTC](https://discourse.julialang.org/t/concrete-vs-parametric-when-determining-type-specificity/104784 "2023-10-10T04:09:04Z")\
**Posts on this page:** 4\
**Page:** 2

<div class="post-metadata">

**Author:** ![ettersi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ettersi/32/6829_2.png) [@ettersi](https://discourse.julialang.org/u/ettersi)\
**Post date:** [October 11, 2023, 2:04am UTC](https://discourse.julialang.org/t/concrete-vs-parametric-when-determining-type-specificity/104784/21 "2023-10-11T02:04:39Z")

</div>

I had a brief look through the [source code](https://github.com/JuliaLang/julia/blob/master/src/subtype.c), and it indeed looks like arguments are considered independently when determining specificity.

My reading of the source code involved a lot of educated guessing, so here’s my reasoning in case anyone wants to double-check:

- According to the [dev docs](https://docs.julialang.org/en/v1/devdocs/types/#Subtyping-and-method-sorting), `jl_type_morespecific(a,b)` is the function which determines method specificity.

- This function first does a couple of checks that AFAICT don’t apply to our case, and then calls `type_morespecific()`.

- Both inputs are tuples, so `type_morespecific()` dispatches to `tuple_morespecific()`:

- `tuple_morespecific()` is quite complicated, but most of the decision-making seems to be based on a variable called `some_morespecific`, which to me sounds a lot like we’re checking whether some of the elements in the first tuple are more specific than their counterparts in the second tuple.

---

<div class="post-metadata">

**Author:** ![Syx\_Pek](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/syx_pek/32/6364_2.png) [@Syx\_Pek](https://discourse.julialang.org/u/Syx_Pek)\
**Post date:** [October 11, 2023, 5:08am UTC](https://discourse.julialang.org/t/concrete-vs-parametric-when-determining-type-specificity/104784/22 "2023-10-11T05:08:37Z")

</div>

How do you check if a type satisfy `jl_is_tuple_type`, the diagonal constraint should cause it not to be a tuple type?

---

<div class="post-metadata">

**Author:** ![ettersi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ettersi/32/6829_2.png) [@ettersi](https://discourse.julialang.org/u/ettersi)\
**Post date:** [October 11, 2023, 5:50am UTC](https://discourse.julialang.org/t/concrete-vs-parametric-when-determining-type-specificity/104784/23 "2023-10-11T05:50:18Z")

</div>

That was one instance of educated guessing 🙈

Basically, I used this as a proxy:

```julia
julia> methods(foo)[1].sig <: Tuple
true

```

It is of course entirely possible that that’s not the test used by `jl_is_tuple_type()`, but it’s the best I could come up with.

---

<div class="post-metadata">

**Author:** ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)\
**Post date:** [October 11, 2023, 6:12am UTC](https://discourse.julialang.org/t/concrete-vs-parametric-when-determining-type-specificity/104784/24 "2023-10-11T06:12:26Z")

</div>

> [@ettersi](#):
>
> My reading of the source code involved a lot of educated guessing, so here’s my reasoning in case anyone wants to double-check:

As far as I can tell, your reasoning is correct & consistent with what I described above 🙂 To be fair, I also only learnt about how this works by reading the source code & piecing it together with the description in the devdocs.

> [@Syx\_Pek](#):
>
> How do you check if a type satisfy `jl_is_tuple_type`, the diagonal constraint should cause it not to be a tuple type?

All function signatures are tuple types. That’s why I translated the `foo(::T, Vector)` to `Tuple{T, Vector{S}} where {T,S}` above.

[Previous page](https://discourse.julialang.org/t/concrete-vs-parametric-when-determining-type-specificity/104784.md?page=1)