methods function doesn't consider methods with keyword arguments

[vtjnash]

probably just a display error:

julia> f(;a=true) = true
f (generic function with 1 method)

julia> f() = false
f (generic function with 1 method)

julia> f()
false

julia> f(;a=false)
true

julia> f|>methods
#1 method for generic function "f":
f() at none:1

related: I thought keyword arguments were getting printed at some point, but that doesn't seem to be true now:

julia> g(;a=true) = true
g (generic function with 1 method)

julia> g|>methods
#1 method for generic function "g":
g() at none:1

[JeffBezanson]

see #2758
Also having methods distinguished only by keyword arguments is not technically allowed.

[vtjnash]

I guess I could rewrite it to use nothing to distinguish the keyword argument, but why isn't it allowed? I initially tried to write it as an optional terminal argument, but it just got annoying to deal with the ambiguity warnings (and the compiler kept calling the wrong method).

[JeffBezanson]

It could be allowed, but there is a confusing corner case: in f(;kw...) you might assume it calls the f with keyword arguments, but what does it do when kw is empty?

[ivarne]

I would say that you call the function with keyword arguments if there is a ; kw... or a arg=val in the call even if kw is empty. I think that is what @stevengj hoped that would happen in #4117 to be able to extend a user implemented method like writemime with keyword arguments

[JeffBezanson]

I'm not sure that's the right behavior; for example now we allow

julia> sin(2.0;{}...)
0.9092974268256817

I don't think this affects the writemime case, since a new (more specific) writemime method with keyword arguments will be called based on its positional arguments, whether keyword args are passed or not.

[vtjnash]

bump

please discuss. it's blocking my pull request (#5971), so I want to be able to work on resolving both

0. arguments against the status quo f() === f(;)

f(;x...) = 1
f() = 2  #= YIKES! user has replaced only half of the method table definitions from the previous line =#

1. arguments for f(;) ≠ f()

• having a ; in the call forces a call to the keyword version, making it possible to call a kw method without specifying keyword arguments. therefore, it's more flexible
• the user must write explicit dispatch functions, but they can go in either direction: f(x...) = f(x...;) or f(x...;) = f(x...)
• however, the user must always be aware of the need to write these extra, explicit dispatch functions (although I expect that the user would typically use one to dispatch to the other -- so the user could have something like sin(2.0;{:method=:libm}...) behave the same as sin(2.0) and sin(2.0;{}...), regardless of which method is called, where
  sin(x;method=:libm) = switch method case :libm; sin(x) case :taylor; taylor_sin(x) case :table; sin(iround(x)) end)

2. arguments for f(;) = f()

• this seems conceptually similar to f(x...) calling f() if x=(), iff f() is also defined
• this behavior (nearly) matches the current bahavior
• i think those bullet points makes this solution better
• however, it is not intrinsically clear to me that sin(2.0; {}...) should be valid
• however, if the compiler stops creating method entries in both tables, f(;) could now be a no method error
• perhaps a compromise is to have the compiler generate a stub f() = f(;) (as it does now) iff a method with the exact same type signature does not already exist, resolving the method declaration order inconsistency seen in case 0

[StefanKarpinski]

I don't really like this business at all. It may be necessary for us to distinguish the no-kw-args version from the zero-kw-args version, but it seems like a horribly fiddly design to me.