# Allow use of named-argument syntax for positional arguments?

**URL:** <https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287>\
**Category:** Internals & Design\
**Tags:** proposal\
**Created:** [August 8, 2017, 7:09pm UTC](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287 "2017-08-08T19:09:15Z")\
**Posts on this page:** 20\
**Page:** 2

<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:** [August 16, 2017, 7:40am UTC](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/21 "2017-08-16T07:40:07Z")

</div>

One thing I frequently do is use one variable name in the documentation, and another one in the actual code. The docstring might say

```julia
crazyawsomevacationpic = enhance(awsomevacationpic)

```

but the code itself has

```julia
function enhance(img::Image)

```

because that’s much more convenient and readable inside the code. If positional variable names are part of the API, how will this work?

Another question regarding the update process:

> [@StefanKarpinski](#):
>
> It’s an extremely awkward and annoying process where the method definition in question retains the old keyword name with a nothing (or other sentinel) default value, and if a different value is passed, it manually calls depwarn to tell the user to change their code to use the new keyword argument, then it assigns the new keyword argument the appropriate value and continues on its way. I don’t think we want to encourage more of this.

Let’s say I decide to, not just change variable names, but to _interchange_ them? I decide that, really, it makes more sense that variable `x` should be called `y` and `y` should be called `x` (I have made changes like that countless times.) That would make for a very awkward deprecation process.

> [@nickeubank](#):
>
> is that such a bad thing that the var names be part of API?

It seems really bad to me. It’s ugly, verbose, intrusive, will cause bugs, and puts an extra unnecessary burden on the developer. When I use positional arguments I _deliberately_ want to hide the names from the caller. When I want named arguments I use kwargs.

Perhaps it could be possible to allow kwargs to also accept positional input, or something like that? Then this would be opt-in behaviour. Otherwise, if a change like this were to come, I hope it will be possible for any developer to turn it off and disallow its use.

---

<div class="post-metadata">

**Author:** ![akdor1154](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/akdor1154/32/15975_2.png) [@akdor1154](https://discourse.julialang.org/u/akdor1154)\
**Post date:** [April 29, 2020, 2:44am UTC](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/22 "2020-04-29T02:44:36Z")

</div>

Three years later, is there any appetite for this?

To add something - there’s very interesting prior art here with Swift. Swift encourages this pattern with one of the same core values as Julia - because code is read more often than it is written.

Swift has a language feature specifically to make this pattern both useful for library consumers, and non-painful for library authors (e.g. the pain points that @DNF raised): The name of the API function parameter (consumer sees) and the name of the bound variable inside the function (author uses) are uncoupled. Example from swift doco:

```swift
func greet(person: String, from hometown: String) -> String {
    return "Hello \(person)! Glad you could visit from \(hometown)."
}
print(greet(person: "Bill", from: "Cupertino"))

```

`from` becomes part of the function api, and `hometown` is free for the library author to change as she sees fit.  
(see [Functions — The Swift Programming Language (Swift 5.7)](https://docs.swift.org/swift-book/LanguageGuide/Functions.html#ID166))

They actually go all-out on this, and by default, all function arguments need to be called with their names (this was done in a major language version change, Swift 3 I think). There is special syntax for functions to allow a parameter to be used without a name (e.g. add(x,y)).  
As someone who migrated a few projects to this new standard, at the time it seemed like a verbose pain in the arse. Looking back at the code now, though, it’s perfectly clear and I actually think this was a really good move.

I would love to see this allowed in Julia - as previous posters stated, I don’t care for variable ordering, it’s more to make my code easier to understand, and as a sanity check to make sure I’m calling other peoples’ libraries correctly.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [April 29, 2020, 2:54am UTC](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/23 "2020-04-29T02:54:42Z")

</div>

As @StefanKarpinski wrote the [very first time keyword arguments were discussed for Julia](https://github.com/JuliaLang/julia/issues/485),

> The main consideration here is making keyword arguments not completely impossibly complicated to understand in the presence of multiple dispatch.

For example, consider what happens if you have

```julia
foo(x::Int, y::String) = 1
foo(y::String, x::Int) = 2

```

and you call `foo(x=3, y="bar")`. Since ordering shouldn’t matter for named arguments, which method should it call?

Or what about

```julia
foo(x::Integer) = 1
foo(y::Int) = 2

```

If you call `foo(x=1)`, should it call the more specific method for `Int` even though the argument was named differently? If not, then are you okay with `foo(x=1) ≠ foo(1)`?

---

<div class="post-metadata">

**Author:** ![akdor1154](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/akdor1154/32/15975_2.png) [@akdor1154](https://discourse.julialang.org/u/akdor1154)\
**Post date:** [April 29, 2020, 3:00am UTC](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/24 "2020-04-29T03:00:55Z")

</div>

To take Stefan’s first example of possible issues here:

```jl
f(x::Int, y::String="") = 2
f(y::String, x::Int=4) = 3

```

> What should `f(x=1, y="x")` give?

It should give 2. If the first definition was not there, it should give the same error that `f(1, "asdf")` would give currently: that no compatible method for these types exist.

What I’m advocating for is that

- dispatch continues to work based on an ordered list of types,
- function parameters can be named at the time of call; if the name of parameter _n_ does not match the declared name of parameter _n_ in the API, an error is thrown.

Applying these to your edits:  
`foo(x=3, y="bar")` should give 1 (dispatch based on order, as it is now).  
`foo(x=1)` should dispatch against `Int` based on ordered list of types, but then error because it was called with `x` and not `y`.

Both of these can be resolved unambiguously and according to current dispatch rules. The second example is admittedly interesting and raises a case that library authors would have to take care with.

As long as they are still referred to and considered to be **positional** arguments I don’t think this is super-confusing.

---

<div class="post-metadata">

**Author:** ![tomerarnon](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tomerarnon/32/3170_2.png) [@tomerarnon](https://discourse.julialang.org/u/tomerarnon)\
**Post date:** [April 29, 2020, 5:50am UTC](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/25 "2020-04-29T05:50:41Z")

</div>

Just landed on this (fun) discussion and figured I’d raise a couple more issues I haven’t seen so far:

- Wouldn’t reading code be _more_ confusing, since named-positional and keyword arguments are both allowed. I.e.

```julia
f(3, y=5) # If I'm someone reading this, is y positional or keyword?

```

- If you have named positional arguments, can you name some but not all of them?

```julia
f(3, y=4, 1) # y is positional, so is this ok?

```

- What do you do if positional and keyword methods are both defined, but they share variable names? E.g.

```julia
f(x, y=1) = x + y
f(x; y=1) = x*y

f(x, y=10) # ?

```

Must this throw an error now to not break existing code that does this?

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [April 29, 2020, 7:08am UTC](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/26 "2020-04-29T07:08:44Z")

</div>

> [@akdor1154](#):
>
> dispatch continues to work based on an ordered list of types

It is not clear to me what determines the ordering. Also, did you mean ordered list of _arguments_?

> [@akdor1154](#):
>
> I don’t care for variable ordering, it’s more to make my code easier to understand

Most people here agree with you: usually more than 2–3 required positional arguments are generally recognized as code smell.

It is just that Julia has different strategies for dealing with this issue than Swift and R.

The most obvious is [keyword arguments](https://docs.julialang.org/en/v1/manual/functions/#Keyword-Arguments-1). In recent Julia versions, they can have no default value, and just error.

Arguably, the nicest for a lot of arguments that are part of some coherent group is wrapping them in a `struct`. This usually has no performance cost, can provide validation and errors at the call site, and reusing these arguments. For a nice example, see [`Optim.BFGS`](https://julianlsolvers.github.io/Optim.jl/stable/#algo/lbfgs/).

---

<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:** [April 29, 2020, 7:39am UTC](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/27 "2020-04-29T07:39:10Z")

</div>

> [@akdor1154](#):
>
> the pain points that @DNF raised

This seems to really just address one of the points I raised: different names facing the user vs inside the code.

It’s still going to be hard to change names if I decide that I made a bad choice in the first place. Or if I just want to harmonize names across different functions. I need to come up with N times as many ‘nice’ user-facing names, increasing the likelihood of name clashes across a codebase, or inconsistent styles between different functions. Now, changing a user-facing name means changing a docstring. With this, I break code.

It makes code more _verbose_, which is really bad in my book, and it would look more messy without a lot of coordination across functions/modules/packages.

This seems like a feature for a different kind of language. It’s for writing big, enterprise-level software, with uniform interfaces written by coordinated teams of paid employees adhering to an enforced style guide.

My function arguments are called `x` or `val` or something like that. Why does that need to spill out into the caller code?

---

<div class="post-metadata">

**Author:** ![akdor1154](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/akdor1154/32/15975_2.png) [@akdor1154](https://discourse.julialang.org/u/akdor1154)\
**Post date:** [April 29, 2020, 8:27am UTC](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/28 "2020-04-29T08:27:24Z")

</div>

> [@tomerarnon](#):
>
> Wouldn’t reading code be _more_ confusing, since named-positional and keyword arguments are both allowed. I.e.
> 
> ```julia
> f(3, y=5) # If I'm someone reading this, is y positional or keyword?
> 
> ```

Yes, I guess as a reader you won’t know. To answer these there would need to be a solution for your third point,

> [@tomerarnon](#):
>
> What do you do if positional and keyword methods are both defined, but they share variable names? E.g.
> 
> ```julia
> f(x, y=1) = x + y
> f(x; y=1) = x*y
> 
> f(x, y=10) # ?
> 
> ```
> 
> Must this throw an error now to not break existing code that does this?

This is an interesting issue that you raise! I guess if there were support for this proposal the first step would be to see how often this arises in practice. In akdor1154’s magic world I would say the behaviour in your example should be positional, requiring a `;` to be interpreted as keyword, but that would be a breaking change, the effects of which could easily go unnoticed.

* * *

> [@Tamas\_Papp](#):
>
> It is not clear to me what determines the ordering. Also, did you mean ordered list of _arguments_ ?

I mean the order of the types of the arguments as used in the user’s function call, which is how dispatch works currently (If I understand dispatch correctly).

* * *

> [@DNF](#):
>
> It makes code more _verbose_ , which is really bad in my book, and it would look more messy without a lot of coordination across functions/modules/packages.

I disagree that verbosity is universally bad. Or alternatively, that more characters means verbosity. How much/little verbosity people will put up with to increase clarity is very subjective, and is just another code style choice that authors should be able to make for themselves.

> [@DNF](#):
>
> It’s still going to be hard to change names if I decide that I made a bad choice in the first place. Or if I just want to harmonize names across different functions.

Yes, but I don’t think it’s any more difficult than just naming the functions in your API in the first place. As an anecdote, in practice, I haven’t seen any issues or anyone complain about this in Swift-land, where this is enforced and used widely.

> [@DNF](#):
>
> My function arguments are called `x` or `val` or something like that. Why does that need to spill out into the caller code?

It doesn’t, no-one is advocating to force either you or users of your library to write `mean(val: myarray)` or anything pointlessly verbose like that.  
Under this proposal that would be possible I guess, but even if someone does that then that’s a) not harmful to you, and b) not the point of this proposal.

> [@DNF](#):
>
> This seems like a feature for a different kind of language. It’s for writing big, enterprise-level software, with uniform interfaces written by coordinated teams of paid employees adhering to an enforced style guide.

It’s certainly helpful in such situations! But the Swift examples I was referring to before were all on my own small codebases, that I share with nobody else, and anecdotally, I appreciated the additional clarity when reading my code for far longer than I detested the extra typing per-parameter.

---

<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:** [April 29, 2020, 8:35am UTC](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/29 "2020-04-29T08:35:16Z")

</div>

> [@akdor1154](#):
>
> I disagree that verbosity is universally bad.

I would say that verbosity is bad in and of itself, but there is a trade-off between offering more information (_can_ be good) and verbosity (universally bad).

> [@akdor1154](#):
>
> How much/little verbosity people will put up with to increase clarity is very subjective, and is just another code style choice that authors should be able to make for themselves.

Yes, that’s how it is now. But with this you would _force_ more verbosity. Or, do you mean that this is optional?

> [@akdor1154](#):
>
> I don’t think it’s any more difficult than just naming the functions in your API in the first place

It’s suddenly a _lot_ more names. Instead of just naming functions, it now function plus 2-3 argument names. That’s a big change.

> [@akdor1154](#):
>
> It doesn’t, no-one is advocating to force either you or users of your library to write `mean(val: myarray)` or anything pointlessly verbose like that.

That’s good. I didn’t catch that. I would definitely opt very much out of this.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [April 29, 2020, 8:36am UTC](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/30 "2020-04-29T08:36:15Z")

</div>

> [@akdor1154](#):
>
> I mean the order of the types of the arguments as used in the user’s function call, which is how dispatch works currently (If I understand dispatch correctly).

Dispatch is not about order, it is a picking a matching method signature that is the narrowest.

The details of your proposal are still very unclear to me.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [April 29, 2020, 8:38am UTC](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/31 "2020-04-29T08:38:46Z")

</div>

> [@DNF](#):
>
> do you mean that this is optional?

I don’t think you can make this optional. Once `x` and `y` are part of the API for `add(x, y)`, a package would have to consider users who are using `add(y = a, x = b)`. Changes that are currently innocuous (eg someone giving more descriptive variable names that show up in autogenerated docstrings) would be breaking.

---

<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:** [April 29, 2020, 8:44am UTC](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/32 "2020-04-29T08:44:36Z")

</div>

There would have to be a way for me to make sure that no-one can call my functions using named arguments.

Another thing, @akdor1154 , what if I want to extend a pre-existing function (written by someone else) for a new type I defined. Would I have to expose the same argument names?

---

<div class="post-metadata">

**Author:** ![akdor1154](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/akdor1154/32/15975_2.png) [@akdor1154](https://discourse.julialang.org/u/akdor1154)\
**Post date:** [April 29, 2020, 8:57am UTC](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/33 "2020-04-29T08:57:56Z")

</div>

> [@Tamas\_Papp](#):
>
> Dispatch is not about order, it is a picking a matching method signature that is the narrowest.

I think we are talking about the same thing … if I write “method signature” (as it means now, e.g. `f(String, Int)`) instead of “the order of the types in the user’s function call”, does that make sense?

> [@Tamas\_Papp](#):
>
> Once `x` and `y` are part of the API for `add(x, y)` , a package would have to consider users who are using `add(y = a, x = b)` .

Hypothetically under this proposal, it would be an error to call `add(y=a, x=b)` as the order of the names don’t match the API of `add(x, y)`, so this situation would not occur.

* * *

> [@DNF](#):
>
> There would have to be a way for me to make sure that no-one can call my functions using named arguments.

That’s not what I meant by optional - I meant callers could optionally write  
`DNFsFunction(samples, 1.5)`  
or `DNFsFunction(data=samples, k=1.5)`,  
just like you’d be able to choose whether to write  
`convert(Array{UInt8}, data)`  
or `convert(to=Array{UInt8}, data)`  
in your own code.

* * *

> [@DNF](#):
>
> Another thing, @akdor1154 , what if I want to extend a pre-existing function (written by someone else) for a new type I defined. Would I have to expose the same argument names?

I don’t see why that would be required in principal; it might annoy users if you give arguments different labels when externally they appear to serve the same purpose as the pre-existing function, though.

---

<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:** [April 29, 2020, 9:00am UTC](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/34 "2020-04-29T09:00:04Z")

</div>

> [@akdor1154](#):
>
> That’s not what I meant by optional - I meant callers could optionally write

But can I write my function such that it is impossible for others to call it with argument names? Because I _really_ want to prevent that.

---

<div class="post-metadata">

**Author:** ![akdor1154](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/akdor1154/32/15975_2.png) [@akdor1154](https://discourse.julialang.org/u/akdor1154)\
**Post date:** [April 29, 2020, 9:01am UTC](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/35 "2020-04-29T09:01:33Z")

</div>

> [@Tamas\_Papp](#):
>
> The details of your proposal are still very unclear to me.

What I have in mind is:

1. choose a method implementation via existing dispatch rules
2. if the user has provided argument labels, and they don’t match the argument labels in the API, error.

Is there ambiguity in here that I have missed?

---

<div class="post-metadata">

**Author:** ![akdor1154](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/akdor1154/32/15975_2.png) [@akdor1154](https://discourse.julialang.org/u/akdor1154)\
**Post date:** [April 29, 2020, 9:04am UTC](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/36 "2020-04-29T09:04:58Z")

</div>

> [@DNF](#):
>
> But can I write my function such that it is impossible for others to call it with argument names? Because I _really_ want to prevent that.

I guess that’s an open question!  
Back to the Swift implementation, they actually _do_ have syntax for this:

```swift
func rgb(_ red: Float, _ green: Float, _ blue: Float) { }

```

So they decided that there were valid use cases for API authors to disallow names.

---

<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:** [April 29, 2020, 9:07am UTC](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/37 "2020-04-29T09:07:30Z")

</div>

> [@akdor1154](#):
>
> I don’t see why that would be required in principal; it might annoy users if you give arguments different labels when externally they appear to serve the same purpose as the pre-existing function, though.

In that case callers would have to know the type of their variables, and call the function with different names depending on which type they were using. That would be bad. The way out would be to not use named arguments in generic code.

But if I want my code to compose well with other peoples code, and they are using named arguments, then I pretty much have to accept the names they are using.

> [@akdor1154](#):
>
> So they decided that there were valid use cases for API authors to disallow names.

That’s good, but also adds verbosity compared to now.

I think that external methods that can be arbitrarily extended by others, makes an awkward fit with this proposal. It’s different when the methods _belong_ to a class, and are under full control of the class author.

---

<div class="post-metadata">

**Author:** ![akdor1154](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/akdor1154/32/15975_2.png) [@akdor1154](https://discourse.julialang.org/u/akdor1154)\
**Post date:** [April 29, 2020, 9:22am UTC](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/38 "2020-04-29T09:22:56Z")

</div>

> [@DNF](#):
>
> In that case callers would have to know the type of their variables, and call the function with different names depending on which type they were using. That would be bad. The way out would be to not use named arguments in generic code.
> 
> But if I want my code to compose well with other peoples code, and they are using named arguments, then I pretty much have to accept the names they are using.

Yes, that’s a good point. I was more considering cases like in DataFrames where they overload stuff in Base but with slightly different argument sets, and where users know they are calling these APIs with a dataframe.  
For generic-type overloading, under this proposal, you should use the same names as the pre-existing method or you’d cause angst for users. I think this would have to be a “best practice” thing though, there are cases where it would be harmful or plain impossible to enforce it.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [April 29, 2020, 11:35am UTC](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/39 "2020-04-29T11:35:03Z")

</div>

> [@akdor1154](#):
>
> Is there ambiguity in here that I have missed?

My understanding of your proposed rules is the following:

1. function argument _names_ (when applicable) and _values_ are collected. eg a call `f(x = 1, y = 3.0)` would have `(:x, :y)` and `Tuple{Int, Float64}`.
2. the `Tuple` of _values_ is matched against function signatures using the current dispatch semantics, eg here `f(x::Int, z::Float64)` would be a match for the purposes of dispatch.
3. _then_ names are checked for the selected method?

Is this correct?

If yes, note that **Julia can do this already with a bit of extra syntax**. Just make a macro `@namedcall f(x = 1, y = 3.0)` that captures the relevant information, eg as a `NamedTuple`, and a `@namedmethod f(x::Int, y::Int)` that defines `f` on a relevant subtype of this `NamedTuple`, inserting an `@assert` about the names (you can of course use shorter/more clever names, I just made these up).

This would make a nice package and allow people to experiment with your idea. If it gains widespread use, arguing for a change of the standard semantics would be much easier.

---

<div class="post-metadata">

**Author:** ![CameronBieganek](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cameronbieganek/32/6915_2.png) [@CameronBieganek](https://discourse.julialang.org/u/CameronBieganek)\
**Post date:** [April 29, 2020, 2:22pm UTC](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/40 "2020-04-29T14:22:35Z")

</div>

I’m quite fond of concise function calls like

```julia
divrem(a, b)
reshape(1:12, 4, 3)
rand(1:9, 10, 20)

```

I think conciseness often _improves_ readability rather than reduces it. There’s a reason mathematical notation is very concise—because it makes abstract concepts easier to read and understand at a glance.

Compare this notation

```julia
μ = Σx / n

```

to this notation

```julia
mean = sum of elements in array / count of elements in array

```

Once one is familiar with mathematical notation, the first example gets the point across much more quickly than the second example. And if you wrote a more complicated equation in words it would be nearly illegible.

A lot of Julia users have a mathematical background and are used to the concise notation of mathematics, so making Julia code more verbose is going to be a hard sell.

[Previous page](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287.md?page=1)

[Next page](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287.md?page=3)