# Named parameters with type overloads

**URL:** <https://discourse.julialang.org/t/named-parameters-with-type-overloads/18860>\
**Category:** General Usage\
**Created:** [December 20, 2018, 5:41pm UTC](https://discourse.julialang.org/t/named-parameters-with-type-overloads/18860 "2018-12-20T17:41:01Z")\
**Posts on this page:** 1\
**Showing post:** 23

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [February 28, 2024, 8:39am UTC](https://discourse.julialang.org/t/named-parameters-with-type-overloads/18860/23 "2024-02-28T08:39:59Z")

</div>

There have been some previous threads about this topic ([Allow use of named-argument syntax for positional arguments?](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287), [Naming positional arguments at call site](https://discourse.julialang.org/t/naming-positional-arguments-at-call-site/103526)), and I daresay it’s a controversial proposal (I’m personally opposed to this.)

I think that in practice, the conclusion on this topic is summarized in the accepted answer from the latest thread:

> [@Naming positional arguments at call site](https://discourse.julialang.org/t/naming-positional-arguments-at-call-site/103526/97):
>
> The problem is that [PSA: Julia is not at that stage of development anymore](https://discourse.julialang.org/t/psa-julia-is-not-at-that-stage-of-development-anymore/44872). This isn’t a simple feature to turn on; it has huge ramifications to the API surface area (and thus maintenance) of all positional-argument functions ever written. It would also have some very confused (and breaking) semantics in the presence of multiple dispatch and existing kwargs.

---

_[View the full topic](https://discourse.julialang.org/t/named-parameters-with-type-overloads/18860)._