Benoit Daloze

In any case I think there needs to be a single way to handle keyword arguments on the callee side. Otherwise we'll have 2 pieces of code out of sync,...

FYI @norswap and I are working on a refactoring of Hash strategies. That might bring some conflicts. I suggest to avoid any new code touching Hash internals if possible, if...

FYI, that refactoring was merged in https://github.com/oracle/truffleruby/commit/6e7a9b038134309ba3b1aab2550ab6e8828ce3e7

That sounds great! What happens for `foo(**h)`? Also use the descriptor in that case since there are keywords arguments on the caller side? I think there is an issue if...

There is also the inverse case of: ```ruby def foo(h) h end p foo(a: 1) ``` It's unclear in such a case if it's beneficial to use the descriptor. I...

Another complication is since Ruby 2.7 any key is allowed in a keyword hash, not just Symbols. So `foo(**h)` might have non-Symbols keys, and the descriptor would need to handle...

> `args.kwhash` is usual logic for finding the keyword argument hash. So that means we would need to have to maintain both paths then when reading kwargs, reading from packed...

It's very good points. I think I don't know of all trade offs yet either. Yes, the call-target-agnostic approach means the callee needs to handle either the packed kwargs, or...

Here are some more discussion points (discussed with Chris). * CallTarget-specific might be more complex in terms of logic, because mix-and-matching caller kwargs with callee kwargs * But CallTarget-agnostic needs...

@wildmaples @chrisseaton Since it seems you prefer the CallTarget-agnostic approach and you're doing the work I say go for it, I think both approaches are good and have their own...