From: eregontp@... Date: 2019-12-19T09:31:38+00:00 Subject: [ruby-core:96329] [Ruby master Misc#16260] Symbol#to_proc behaves like lambda, but doesn't aknowledge it Issue #16260 has been updated by Eregon (Benoit Daloze). Status changed from Rejected to Open I agree with @zverok here, a method behaves as a lambda, and doesn't unpack arguments (except a few special methods that specifically do that). @nobu I think we should merge your PR. Could you show an example a Symbol#to_proc behaves like a proc and not a lambda? I think that's only rare exceptions, and so Symbol#to_proc should acknowledge it's a lambda. ---------------------------------------- Misc #16260: Symbol#to_proc behaves like lambda, but doesn't aknowledge it https://bugs.ruby-lang.org/issues/16260#change-83241 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Assignee: ---------------------------------------- Seems that `Symbol#to_proc` returns `Proc` that has lambda semantics: ```ruby proc = :+.to_proc proc.call(1, 2) # => 3 proc.call([1, 2]) # ArgumentError (wrong number of arguments (given 0, expected 1)) ``` But if you ask... ```ruby proc.lambda? # => false ``` That seems to be an inconsistency, which I'd like to clarify. There are obviously two ways to fix it: 1. Make it respond `true` to `lambda?` (and mention the semantics in docs) 2. Make it behave like non-lambda. The second one seems to produce some useful behavior: ```ruby # Currently: [1, 2].zip([3, 4]).map(&:+) # ArgumentError (wrong number of arguments (given 0, expected 1)) # With non-lambda: class Symbol def to_proc proc { |o, *a| o.send(self, *a) } end end [1, 2].zip([3, 4]).map(&:+) # => [4, 6] ``` Probably all of it was discussed when `Symbol#to_proc` was introduced, but as old NEWS-files doesn't link to tickets/discussions, I can't find the reasoning for current behavior. -- https://bugs.ruby-lang.org/ Unsubscribe: