Bug #11048: blocks raise on missing and extra keyword args

• Status: Rejected
• Assignee: matz (Yukihiro Matsumoto)
• Target version: -
• ruby -v: ruby 2.2.1p85 (2015-02-26 revision 49769) [x86_64-linux]
• Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN

[bughit (bug hit)]

blocks intentionally tolerate arity mismatches

irb(main):001:0> proc{|a, b| [a, b]}.(1)
[
  [0] 1,
  [1] nil
]

irb(main):003:0> proc{|a, b|[a, b]}.(1, 2, 3)
[
  [0] 1,
  [1] 2
]

so why not missing keyword args?

irb(main):002:0> proc{|a:, b:|[a, b]}.(a: 1)
ArgumentError: missing keyword: b


irb(main):004:0> proc{|a:, b:|[a, b]}.(a: 1, b: 1, c: 1)
ArgumentError: unknown keyword: c

[ko1 (Koichi Sasada)]

• Assignee set to matz (Yukihiro Matsumoto)

[matz (Yukihiro Matsumoto)]

We don't care about consistency here. Block does not report ArgumentError for reasons, so if you have any real-world use case that require keyword argument tolerance, just tell me. Otherwise I reject.

Matz.

[bughit (bug hit)]

Yukihiro Matsumoto wrote:

We don't care about consistency here. Block does not report ArgumentError for reasons,

What are those reasons? And why do they not apply to keyword arguments?

so if you have any real-world use case that require keyword argument tolerance, just tell me.

The real-world use case is that anyone who has learned that blocks intentionally tolerate arity mismatches, would expect the same for keyword args and will therefore be unpleasantly surprised and be more likely to introduce a bug.

And that's the value of consistency (or least surprise), behavior that is logically consistent, that can be inferred without having to remember countless of arbitrary special case rules, avoids surprise and bugs.

Since you value programmer joy, there is little joy in having to keep track of incoherent, inconsistent special case rules.

[bughit (bug hit)]

Yukihiro Matsumoto wrote:

so if you have any real-world use case that require keyword argument tolerance, just tell me.

The way I discovered this, as far as I remember, is:
I encountered a method I needed to call that yielded keyword args
In my case I only cared about one arg so I passed a block taking one keyarg, expecting it to just quietly drop the others as with positional args
Instead it raised

[matz (Yukihiro Matsumoto)]

For example, loop method passes loop counter to the block. You can safely ignore this by arity tolerance. This is a reason behind it. But there's no benefit for keyword arguments tolerance, as far as I see, but demerit of late error detection.

Matz.

[bughit (bug hit)]

Yukihiro Matsumoto wrote:

For example, loop method passes loop counter to the block. You can safely ignore this by arity tolerance. This is a reason behind it. But there's no benefit for keyword arguments tolerance, as far as I see, but demerit of late error detection.

Matz.

If you believe there's value in being able to ignore args you don't care about, I don't see why it would not apply to keyargs. The difference is not so fundamental, both are used to pass data to the block. One might switch to keyargs for yield, to make the code clearer, but there would be no expectation of this difference in behavior.

[matz (Yukihiro Matsumoto)]

• Status changed from Open to Closed

OK, you value consistency, where I value pragratic trade-off. That's the difference in view points.
Let's agree to disagree.

Matz.

[usa (Usaku NAKAMURA)]

• Status changed from Closed to Rejected

[bughit (bug hit)]

another use case for this is hash destructuring

array_of_hashes.each do |key1:, key2:|
end

it would be much better if this code did not raise on extra or missing keys, otherwise this type of destructuring is almost completely impractical

[bughit (bug hit)]

bug hit wrote:

another use case for this is hash destructuring

array_of_hashes.each do |key1:, key2:|
end

it would be much better if this code did not raise on extra or missing keys, otherwise this type of destructuring is almost completely impractical

Please comment on the use case of hash destructuring via block keyword args.