# To Adopt mandatory semicolon in method calls if kwargs are passed
**URL:** https://discourse.julialang.org/t/to-adopt-mandatory-semicolon-in-method-calls-if-kwargs-are-passed/43651
**Category:** Internals & Design
**Tags:** proposal
**Created:** [July 25, 2020, 1:56am UTC](https://discourse.julialang.org/t/to-adopt-mandatory-semicolon-in-method-calls-if-kwargs-are-passed/43651 "2020-07-25T01:56:48Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@josePereiro](https://discourse.julialang.org/u/josePereiro)
#### Post date: [July 25, 2020, 1:56am UTC](https://discourse.julialang.org/t/to-adopt-mandatory-semicolon-in-method-calls-if-kwargs-are-passed/43651/1 "2020-07-25T01:56:48Z")
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?](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287):
>
> 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](https://discourse.julialang.org/t/kwargs-in-new-or-safer-ways-of-constructing-immutable-structs/43555):
>
> 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
```julia
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:
```julia
c = 1
# more code
fun(1, 3; c = c) # (1)
```
This is redundant.
I currently do:
```julia
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:
```julia
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_
```julia
# or
c = 1
# more code
fun(1, 3; c) # (5)
# which current equivalent is
fun(1, 3 [,;] c = c) # (6)
```
```julia
# or
fun(1) # (7)
# which current equivalent is
fun(1) # (8)
```
```julia
# 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](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/53).
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
```julia
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](https://github.com/JuliaLang/julia/milestone/23). Although, automatic ways of adding or warning the missing semicolons are possible, maybe in the 0.7 equivalent for 2.0.
Thanks!
---
### Author:  [@yuyichao](https://discourse.julialang.org/u/yuyichao)
#### Post date: [July 25, 2020, 2:58am UTC](https://discourse.julialang.org/t/to-adopt-mandatory-semicolon-in-method-calls-if-kwargs-are-passed/43651/2 "2020-07-25T02:58:11Z")
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](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/50) 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.
---
### Author:  [@josePereiro](https://discourse.julialang.org/u/josePereiro)
#### Post date: [July 25, 2020, 3:42am UTC](https://discourse.julialang.org/t/to-adopt-mandatory-semicolon-in-method-calls-if-kwargs-are-passed/43651/3 "2020-07-25T03:42:35Z")
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](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287) 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
> [@Kwargs in new(), or safer ways of constructing immutable structs](https://discourse.julialang.org/t/kwargs-in-new-or-safer-ways-of-constructing-immutable-structs/43555/1):
>
> 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:
> [@Allow use of named-argument syntax for positional arguments?](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/42):
>
> 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?](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287/50) instead
That’s ok, I just wanted to focus on the idea of make semicolon mandatory because help to solve other problems/issues
---
### Author:  [@yuyichao](https://discourse.julialang.org/u/yuyichao)
#### Post date: [July 25, 2020, 4:00am UTC](https://discourse.julialang.org/t/to-adopt-mandatory-semicolon-in-method-calls-if-kwargs-are-passed/43651/4 "2020-07-25T04:00:42Z")
> [@Kwargs in new(), or safer ways of constructing immutable structs](https://discourse.julialang.org/t/kwargs-in-new-or-safer-ways-of-constructing-immutable-structs/43555/1):
>
> > [@Kwargs in new(), or safer ways of constructing immutable structs](https://discourse.julialang.org/t/kwargs-in-new-or-safer-ways-of-constructing-immutable-structs/43555/1):
> >
> > 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?](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287). 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.
---
### Author:  [@josePereiro](https://discourse.julialang.org/u/josePereiro)
#### Post date: [July 25, 2020, 4:07am UTC](https://discourse.julialang.org/t/to-adopt-mandatory-semicolon-in-method-calls-if-kwargs-are-passed/43651/5 "2020-07-25T04:07:53Z")
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?
---
### Author:  [@yuyichao](https://discourse.julialang.org/u/yuyichao)
#### Post date: [July 25, 2020, 4:09am UTC](https://discourse.julialang.org/t/to-adopt-mandatory-semicolon-in-method-calls-if-kwargs-are-passed/43651/6 "2020-07-25T04:09:02Z")
No, I’m simply saying it is **not a solution**. The problem is completely somewhere else.
---
### Author:  [@josePereiro](https://discourse.julialang.org/u/josePereiro)
#### Post date: [July 25, 2020, 4:11am UTC](https://discourse.julialang.org/t/to-adopt-mandatory-semicolon-in-method-calls-if-kwargs-are-passed/43651/7 "2020-07-25T04:11:04Z")
Ummm, I really don’t see why. I will use your attention an ask you why? 🙂
---
### Author:  [@yuyichao](https://discourse.julialang.org/u/yuyichao)
#### Post date: [July 25, 2020, 4:11am UTC](https://discourse.julialang.org/t/to-adopt-mandatory-semicolon-in-method-calls-if-kwargs-are-passed/43651/8 "2020-07-25T04:11:50Z")
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?](https://discourse.julialang.org/t/allow-use-of-named-argument-syntax-for-positional-arguments/5287)