# Need for explicitly defining subtypes in function arguments?

**URL:** https://discourse.julialang.org/t/need-for-explicitly-defining-subtypes-in-function-arguments/104883
**Category:** New to Julia
**Created:** [October 12, 2023, 3:20am UTC](https://discourse.julialang.org/t/need-for-explicitly-defining-subtypes-in-function-arguments/104883 "2023-10-12T03:20:43Z")
**Posts on this page:** 1
**Showing post:** 30

<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 13, 2023, 4:49pm UTC](https://discourse.julialang.org/t/need-for-explicitly-defining-subtypes-in-function-arguments/104883/30 "2023-10-13T16:49:33Z")

</div>

> [@hatmatrix](#):
>
> but I see now there is a different philosophy/justification for type invariance.

Since noone seems to have linked it so far, there’s also this explanation by @StefanKarpinski (though with a slight Rust bend, as that was the original question there):

> [@Reason behind designing parametric types as invariant](https://discourse.julialang.org/t/reason-behind-designing-parametric-types-as-invariant/18971/2):
>
> In a sense we do: If we look at our table of variances, we see that &mut T is invariant over T . As it turns out, this completely fixes the issue! Since all types in Julia behave like &mut T in Rust (or at least there’s no way of expressing anything else in the type system—there are immutable types and reference types but they are all treated uniformly), that fact translated to Julia would imply that all parametric types are invariant, which is precisely what we do. In order to do somet…

---

_[View the full topic](https://discourse.julialang.org/t/need-for-explicitly-defining-subtypes-in-function-arguments/104883)._