interpret call f(; x, y) as f(; x=x, y=y)

[KristofferC]

Sorry if this is a dup but I couldn't find one.

I find it quite common that one calls functions with keyword arguments like

f(; x=x, y=y, this_was_a_bit_long=this_was_a_bit_long)

My proposal is to write this as

f(;x, y, this_was_a_bit_long)

and to parse that to the first example.

Since

f(; x, y)

is already a syntax error, I think this should be possible?

[yuyichao]

This is implementable as a macro if you really need it and it doesn't enabling doing anything that couldn't be done while making the syntax much more confusing (even more so than the significance of ; in the function definition).

It'll also give f(; :a=>b) and x = :a=>b; f(; x) completely different meanings.

[KristofferC]

This is implementable as a macro

Of course, the whole point of introducing this as syntax is to avoid a macro.

It'll also give f(; :a=>b) and x = :a=>b; f(; x) completely different meanings.

f(a=b) and x = a=b; f(x) already have completely different meanings. I don't think people find that very confusing.

[KristofferC]

I see Rust has something similar for their kwarg constuctors https://doc.rust-lang.org/book/2018-edition/ch05-01-defining-structs.html#using-the-field-init-shorthand-when-variables-and-fields-have-the-same-name.

[yuyichao]

f(a=b) and x = a=b; f(x)

For start, = is not an operator so that's very different.

And it did cause issues with macros in corner cases.

[ararslan]

My biggest concern over this is that really it shouldn't matter what name you've given to a variable, but in this case you have to be careful if you rename anything, because it can subtly change behavior when using keyword arguments. Instead of just being able to rename your variable, you have to comb through all potential uses of it in this context, and if you miss one you get an unsupported keyword argument error (if you're lucky) or a different result entirely (if you aren't).

[KristofferC]

My biggest concern over this is that really it shouldn't matter what name you've given to a variable, but in this case you have to be careful if you rename anything, because it can subtly change behavior when using keyword arguments.

This argument is a bit late, you do already have to comb through potential uses, e.g.

function f()
    s = 0
    let
        a = 3
    end
    return s
end

Renaming the variable a to some other name might give you a completely different behavior (e.g by calling it s).

[yuyichao]

Renaming the variable a to some other name might give you a completely different behavior (e.g by calling it s).

This isn't a defence at all. It's all about the "subtleness" of the change and more precisely, the localness of the effect.

Of course you can't rename a variable that override another one without any observable effect. You don't even need that let, a = 1; b = 2 will obviously be different if you rename b to a. However, the effect is caused by something that is in the same scope (by which I include parents and children ones). You can easily infer locally whether the override can happen or not. This is also why macro hygiene is so important, you can't expect the user to avoid naming conflict with name introduced in a invisible way by the macro author.

Edit: The effect of renaming a variable in this PR though, is not local. It's observable from not just the scope you see, but also from the callee scope. A macro can serve as a clear marker of customized evaluation rule so it won't be too bad for the reader. The syntax proposed here, however, allows this to happen in a much more subtle way.

[JeffBezanson]

This is already implemented here, commented out:

julia/src/julia-syntax.scm

Line 1746 in 8484f97

((symbol? el) ;; x => x = x

It's done during lowering, since f(; x) and f(; x=x) of course parse differently.

Given the precedent in Rust and other languages with some kind of object notation (e.g. C#, VB, JS) I think this is a reasonable feature. Some commentary from David Anthoff: #22194 (comment)