What exactly is args in the "forward all args" example and how can it work?

Why not pass only positional args with * and only named arguments with ** ?

PEP 3102 -- Keyword-Only Arguments might be an interesting read since you're mentioning this idea. Because otherwise this is probably more similar to Python than Ruby at this point.

@BlaXpirit args would be a tuple with all the positional arguments and also, in the last position, a named tuple with the named args. But it felt like a hack, and we chose to do that mostly because Ruby kind of does that, but when I try to explain this it's confusing and feels like magic, so I decided to remove this. Now you have to be explicit: I updated the original PR description with this.

That said, I really (I mean, really ❤️) like that PEP you mention. I think it's perfect, because the logic is super simple (both for a human and a compiler), and it's also a way to force arguments to be passed as named arguments. And it also open the possibility to overload based on these required named arguments:

# Warning, silly example follows
def print(array : Array)
end

def print(array : Array, *, without)
  print array.delete(element)
end

def print(array : Array, *, and_also)
  print array
  print and_also
end

print [1, 2, 3] # calls the first overload
print [1, 2, 3], without: 2 # calls the second overload
print [1, 2, 3], and_also: 4, # calls the third overload

This for example is possible in Swift. And because arguments after the * necessarily have to be passed as named arguments, they can be part of a method's signature. I want to implement this 😸 . I'll check with @waj, but I'm sure he'll like it too (he likes this in Swift and wants this in Crystal).

The only "downside" (not a downside for me, though), it that right now it's possible to have this in Crystal (and, well, Ruby):

def foo(x, *args, y)
end

foo 1, 2, 3, 4 # x is 1, args is {2, 3}, y is 4

However, I never found a useful use case for that. And in any case, I think invoking it like this is much clearer:

foo 1, 2, 3, y: 4

One clear example of this is the current delegate macro. Right now it's like this:

# One required positional arguments, other optional arguments, and the final argument
# is the one we'll delegate the method to
macro delegate(method, *other_methods, to_object)
end

# delegate foo and bar to baz
delegate foo, bar, baz

# Can't invoke it like this, because right now it's confusing
delegate foo, bar, to_object: baz

If apply the PEP we can write it like this:

macro delegate(*methods, to)
end

delegate foo, to: bar
delegate foo, bar, to: baz

I mean, the definition is shorter and easier to implement, and at the caller side we are forcing a nice, readable syntax. It's a total win.

If we decide to go that way (following the last comment), I'll probably merge this first because it has the logic for the double splat, and then update the matching logic accordingly.

Seems pretty clean, the PEP-definition, I can definitely live without post-splat "positional slots".

@BlaXpirit @ozra I'll try to implement it and then send a PR