Given the possibility to write a lot of generic functions, I am sometimes torn between giving function arguments a descriptive name and the desire to have short argument names for use in the function body.
E.g.: Having f(u,t,p)
instead of f( state, time, parameters )
Swift has the notion of outer and inner names ( so f( state:u, time:t, parameters:p )
) with the possibility to have outer name _
if it is not needed. This would also be nice for IDEs because they could show the function with its descriptive outer names.
Personally I would like to see this in julia also and would love to hear your thoughts about it.
As far as I see this is non-breaking.
You can choose arbitrary names of variables in the docstring for the function, so documentation and help in the repl could use descriptive names.
I don’t think it could get simpler than
"""
$(DocStringExtensions.SIGNATURES)
"""
function f(state, time, parameters)
u, t, p = state, time, parameters
...
end
So does the compiler optimize out the extra names? Or does it increase memory allocation?
In Julia, variables are just labels attached to values, and only values actually occupy memory, regardless of how many ways they have been labeled. In other words, this:
function foo(x)
y = x
z = x
q = x
return 2 * q
end
and this:
function foo(x)
return 2 * x
end
are equivalent in their memory usage and performance.
Julia practice favors meaningful names that, while terse, are not obscure. Naming/ShortForms.md at master · JuliaPraxis/Naming · GitHub
The marginal cost of additional keypressing is being weighed against the marginal benefit of working with more semantically transparent names. While any cost is unshared, the benfit (often) is shared. There is an accrual of value to the community in one case, and at best a non-dimunition of value in the other.