[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: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>