To Adopt mandatory semicolon in method calls if kwargs are passed

[josePereiro]

Hi,
I make semicolon keys for living and I just wanna extend my market beyond C-like languages.
Author Note: Initial joke for relaxing angry people because of the title

A good and clear interpretation of semicolon in method definitions and calls, in my opinion, is that separate what is used in dispatch from what is an optional (keyword) parameter.

My proposal is to remove the optional use of semicolon when calling methods. But arguments before the semicolon will be treated just as current positional arguments and parameters after the semicolon like current keyword arguments.

So, what changes?
Well, now you can add some requested features like

Allow use of named-argument syntax for positional arguments?

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 1:how_many_times_I_print println(the_number_I_print) end end # OK f(2) # Not ok... f(the_number_I_print=2) So long as one abides by things like no positional arguments after keyword…

or help in situations like

Kwargs in new(), or safer ways of constructing immutable structs

When creating an immutable struct with a reasonable number of fields and an inner constructor, I find that aligning the arguments to new() with the order of the struct fields to be quite tedious and error prone (especially if adjacent fields have the same type, or I add / reorder types). With a mutable struct, I tend to do the following: ret = new() ret.x = x ret.y = y ret.z = z ... return ret Which is much safer and easier to maintain. Does anyone have a nice approach to this? It seems like n…

and more…

Lets define

function fun(a, b = 2; c = 3, d = 4)
    # Bla bla good and type stable code
end

Im personally here because I really hate situations like:

c = 1
# more code
fun(1, 3; c = c) # (1)

This is redundant.

I currently do:

c_ = 1
# more code
fun(1, 3; c = c_) # (2)

To diminish the pain a little

If the semicolons are mandatory, now, because the caller will explicitly say what it is a positional or an optional parameter you will be able to have fun calls like:

fun(1, b = 3; c = 3, d = 4) # (3)
# which current equivalent is
fun(1, 3 [,;] c = 3, d = 4) # (4)

[,;] means comma or semicolon

# or
c = 1
# more code
fun(1, 3; c) # (5)
# which current equivalent is
fun(1, 3 [,;] c = c) # (6)

# or
fun(1) # (7)
# which current equivalent is
fun(1)  # (8)

# or
fun(b = 1, a = 2; c = 3, d = 1) # (9)
# or
fun(a = 1, h = 2; c = 3, d = 1) # (10)
# which current equivalent is
# (...)

We may discuss if the names of the positional arguments are just sugar or must match the function definition, discussion in above link.

But, in my opinion, keeping explicit that dispatch is determined by order and type is important. The semicolon will be just doing that!

In the case of (5) being better than (1) or (2) I’m not really open to debate

Just like rigth now, the call

g = 1
fun(1, 2; g) # (11)
# which current equivalent is
fun(1, 2 [,;] g = g) # (12)

Must throw a MethodError (g is not a fun kwarg).

I know this is a breaking proposal, so, it could be included in the 2.0 Milestone. Although, automatic ways of adding or warning the missing semicolons are possible, maybe in the 0.7 equivalent for 2.0.

Thanks!

[yuyichao]

Requiring a semicolon helps nothing here.

@josePereiro

So, what changes?
Well, now you can add some requested features like

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 1:how_many_times_I_print println(the_number_I_print) end end # OK f(2) # Not ok… f(the_number_I_print=2) So long as one abides by things like no positional arguments after keyword…

Nope, the only issue there is dispatch, and the fact that argument name is not a property of a function but that of a method. It’s impossible to do without keyword argument.

@josePereiro

or help in situations like

When creating an immutable struct with a reasonable number of fields and an inner constructor, I find that aligning the arguments to new() with the order of the struct fields to be quite tedious and error prone (especially if adjacent fields have the same type, or I add / reorder types). With a mutable struct, I tend to do the following: ret = new() ret.x = x ret.y = y ret.z = z … return ret Which is much safer and easier to maintain. Does anyone have a nice approach to this? It seems like n…

Nope, it helps nothing there either. new is defined clear enough that it doesn’t need help to distinguish between positional and keyword arguement. Implementing it requires quiet a bit of change but this isn’t one of them.

@josePereiro

If the semicolons are mandatory, now, because the caller will explicitly say what it is a positional or an optional parameter you will be able to have fun calls like:

No, again, the issue is dispatch.

---

And to make it more clear, ; is optional in the call for keyword argument simply because there isn’t any way sensible to interpret a named positional argument. If you have a plan to change that, which should be discussed in Allow use of named-argument syntax for positional arguments? - #50 by akdor1154 instead, requiring ; in some cases is literally the easist step to take. Without it, there’s zero reason to do any syntax change that has no purpose…

All the current “equivalent to” you show are syntactic transformation. Most of what you are proposing are not. They all require knowledge of the callee and that’s simply impossible.

[josePereiro]

Thanks for the quick reply!

@yuyichao

and the fact that argument name is not a property of a function but that of a method.

Upps, my mistake!

@yuyichao

there isn’t any way sensible to interpret a named positional argument.

I see that this is a controversial topic, that’s why discution in posted link exist.

@yuyichao

Nope, it helps nothing there either. new is defined clear enough that it doesn’t need help to distinguish between positional and keyword arguement.

Yes, but I found

@Benjia

I find that aligning the arguments to new() with the order of the struct fields to be quite tedious and error prone (especially if adjacent fields have the same type, or I add / reorder types).

To have named arguments can help there too.

@yuyichao

Nope, the only issue there is dispatch

Yes, but I think a solution that do not change how dispatch works and add the features people already like from other languages can be found. What is proposed do not touch dispatch, I think?

I found in that discussion, as an example:

@StefanKarpinski

The trouble with this is that you need to know which arguments passed with key = val syntax are positional and which are keyword arguments before you can choose a method. But you don’t know that until you’ve selected a method. For example, if I see f(x = 1, y = 2, z = 3) how do I know which subset of x , y and z are positional and should be used to dispatch f and which are keywords and should be ignored during dispatch? There are 8 = 2^3 possibilities to consider and that number grows exponentially with the number of arguments.

As the proposal say f(x = 1, y = 2, z = 3) will be interpreted as current call f(1, 2, 3) and the ambiguity is gone, just because semicolon is mandatory. To be able to optionally label positional arguments is not like REALLY important, but it is cool.

@yuyichao

If you have a plan to change that, which should be discussed in Allow use of named-argument syntax for positional arguments? instead

That’s ok, I just wanted to focus on the idea of make semicolon mandatory because help to solve other problems/issues

[yuyichao]

@josePereiro

@Benjia

I find that aligning the arguments to new() with the order of the struct fields to be quite tedious and error prone (especially if adjacent fields have the same type, or I add / reorder types).

I’m not saying you can’t have named argument for new. I’m saying that if you want to add such support, it doesn’t need any help to distringuish between them. In particular, a named argument can’t have any other meaning.

@josePereiro

Yes, a solution that do not change how dispatch works and add the features people already like from other languages can be found. What is proposed do not touch dispatch, I think?

Yes. I’m not making any argument about Allow use of named-argument syntax for positional arguments?. I’m simply saying the semicolon is completely unrelated and unimportant.

@josePereiro

That’s ok, I just wanted to focus on the idea of make semicolon mandatory because help to solve other problems/issues

Right, and I’m saying that the idea of making semicolon madatory helps none of the problems/issues. Those are all not done for much deeper reasons and it doesn’t make sense to talk about this syntax without any concusion on those.

And just to make it more clear, I’m not making any argument for or against any of the new syntax you are proposing. I’m simply saying that none of what you are proposing are related to semicolons.

---

And again, a non-“mandatory” semicolon simply means that the semicolon does not change the meaning, this is only the case when put in front of named arguments in function call. The only reason one would want to change it would be to give named argument before and after the semicolon a different meaning. That’s the only thing the discussion should focus on but there’s no such proposal here other than the linked thread.

[josePereiro]

Ummm, are you saying there are smarter ways of solving f(x = 1, y = 2, z = 3) posicional/kwarg ambiguity without using method calls mandatory semicolon? You are probably right

But, just for my peace of mind. Is mandatory semicolon one possible solution?, at least?

[yuyichao]

No, I’m simply saying it is not a solution. The problem is completely somewhere else.

[josePereiro]

Ummm, I really don’t see why. I will use your attention an ask you why?

[yuyichao]

Or in another word, the “posicional/kwarg ambiguity” isn’t the problem. Some solutions to the dispatch problem might benefit from such a distinction but that should be discussed as part of those solutions, but,

1. It’s unclear if any good solution exists for the dispatch problem. (i.e. it’s too early to talk about this level of detail, especially since it’s the easiest part…)
2. As I said above, it should be part of Allow use of named-argument syntax for positional arguments?