I’m fond of naming my arguments for readability. Is there a structural reason that one cannot use the names of arguments when the function defines they as positional? In other words, is there a technical reason I can’t do: f = function(the_number_I_print; how_many_times_I_print=1) for i in …

[image] 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: func rgb(_ red: Float, _ green: Flo…

[image] 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, …

[image] 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 ot…

[image] akdor1154: Is there ambiguity in here that I have missed? My understanding of your proposed rules is the following: 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}. the Tuple of values is mat…

I’m quite fond of concise function calls like 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 glanc…

[image] akdor1154: I would love to see this allowed in Julia This feature already exists. Here’s the syntax: function f(; person::String, from::String) hometown = from return "Hello, $(person)! Glad you could visit from $hometown." end julia> f(person = "Bill", from = "Cupertino") "…

[image] akdor1154: What I have in mind is: choose a method implementation via existing dispatch rules 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? The trouble with this is that you need …

I’m going to second what Stefan just said. It seems like the proposal mostly centers around wanting functions to be called with explicitly named arguments. You can already do this with keyword arguments.

I understand the reasons given against named arguments syntax and don’t have a solution for them. However, the current situation definitely has some rough edges and inconsistencies that would not arise at all if naming any arguments was allowed. Several examples from widely used mature libraries: #…

There are several ways that the API in Base could be made more consistent — this was done prior to 0.7/1.0 and it can be done again for 2.0. You may want to check if there is an existing issue for things you notice, and if not, open one and ask for a 2.0 milestone. That said, in [image] aplavin…

Allow use of named-argument syntax for positional arguments?

Internals & Design

akdor1154 June 30, 2020, 12:42am 50

Exactly right.

To Adopt mandatory semicolon in method calls if kwargs are passed

Topic		Replies	Views
Naming positional arguments at call site Internals & Design	131	5514	September 21, 2023
Named parameters with type overloads General Usage	34	2558	February 29, 2024
To Adopt mandatory semicolon in method calls if kwargs are passed Internals & Design proposal	7	1676	July 25, 2020
The death of optional arguments? Internals & Design	37	3000	April 9, 2018
Make function arguments positional or keyword General Usage functions , keyword-arguments	35	4201	October 19, 2018

Allow use of named-argument syntax for positional arguments?

Related topics